Methods and systems for providing and controlling cryptographic secure communications terminal providing a remote desktop accessible in secured and unsecured environments

ABSTRACT

Methods and systems for operating a remote desktop client from a computing system hosting a secure boot device. In some embodiments, a method comprises initiating execution of an operating system from the computing system hosting the secure boot device, the computing system communicatively connected within a secure enterprise network, the computing system being untrusted within the secure enterprise network and based on verification of received authentication credentials, booting an operating system from the secure boot device and establishing a secure communication tunnel with a service appliance. Further, the method comprises receiving, from the service appliance a destination address of a secure gateway device connected to the enterprise network and community of interest keys and filters based on the authenticated credentials; and establishing a cleartext communication channel with the secure gateway device, thereby allowing communication between the computing system and one or more trusted endpoints within the secure enterprise network.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority of U.S. ProvisionalPatent Application No. 62/266,068 filed on Dec. 11, 2015 and U.S.Provisional Patent Application No. 62/266,063 filed on Dec. 11, 2015 andU.S. Provisional Patent Application No. 62/266,053 filed on Dec. 11,2015. All are incorporated by reference in their entirety.

The present application claims priority to U.S. patent application Ser.No. 13/105,154 (Attorney Docket No. TN533), filed on May 11, 2011, andentitled “Methods and Systems for Providing and ControllingCryptographically Secure Communications Across Unsecured NetworksBetween a Secure Virtual Terminal and a Remote System”, which furtherclaims priority to U.S. Provisional Patent Application No. 61/389,535,filed Oct. 4, 2010, and entitled “System and Method for Providing aStealth Secure Virtual Terminal”, Attorney Docket No. TN533.P, thedisclosure of which is hereby incorporated by reference in its entirety.

This application further claims priority, through U.S. patentapplication Ser. No. 13/105,154, to U.S. Provisional Patent ApplicationNo. 61/389,511, filed Oct. 4, 2010, and entitled “System and Method forProviding a USB Stick-Based Thin Client”, Attorney Docket No. TN521.P,the disclosure of which is hereby incorporated by reference in itsentirety.

This application further claims priority, through U.S. patentapplication Ser. No. 13/105,154, to U.S. patent application Ser. No.11/714,598, filed Mar. 6, 2007, entitled “Gateway for Securing Datato/from a Private Network”, Attorney Docket No. TN400.US-CIP3, thedisclosure of which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

The present application relates generally to secured data communication.In particular, the present application relates to methods and systemsfor providing and controlling secure communications across unsecurednetworks.

BACKGROUND

Security is often maintained in organizations by segregating physicalnetworks used by each group of users. This acts to restrict access todata available on computers and databases used in such networks. Forexample, it prevents someone in engineering from gaining access to dataused in the payroll department's network and vice versa. While separatelocal network infrastructures help to maintain security of data,superfluous equipment and maintenance is required to maintain thesesegregated networks. This adds expense, and complexity to the datainfrastructures of such organizations.

Furthermore, regardless of the organizational structure of networks usedin commercial, governmental, and other settings, there is an everincreasing security concern that sensitive data transmitted or stored onlocal networks will be accessed by an unauthorized individual oraccidentally accessed or disclosed outside of a community-of-interest,hence compromising the secret data. Exacerbating this problem is thefact that security threats can also often originate from insiders.Whether the threat is intentional or unintentional, transmitting dataexclusively in one security level partitioned network or another doesnot protect the data if it is in plaintext format. This is because evenstrict physical segregation of a network by security level is noguarantee that data will not be disseminated to end-users outside thatsecurity level.

The above security concerns are only further exacerbated when access toopen or public networks is provided or required, for example in the caseof accessing secure networks remotely via the Internet. For example, thegrowth of the Internet and related network communication networks hasgiven rise to increasingly larger numbers of distributed informationprocessing systems in which individual users obtain information from anever increasing number of sources. For example, in the banking industry,electronic communications by customers to their banking institutions toengage in electronic financial transactions is an increasing form ofinteraction between the customers and the banks. Other organizations orinstitutions requiring highly secured communications overtypically-unsecure networks have analogous problems.

In making these transactions possible, customers use any number ofcomputing systems attached to the Internet to communicate with serversoperated by their banking institutions to send commands and receive dataassociated with these transactions. Banks are typically not able tocontrol the customer's computing systems in a meaningful way that maygive rise to potential security issues. A summary of some of thesesecurity threats are described in detail in a Unisys White Paperentitled “Zeus Malware: Threat Banking Industry” that is incorporatedherein by reference in its entirety.

Still further issues arise when attempting to accommodate differenttypes of connections to a secure enterprise, because traditional secureconnection types (e.g., VPN) do not allow users attempting to connect toa network from within that network to establish such securecommunications. As such, for individuals who may wish to use a portablecomputing system either within or outside of a network, all usage withsecure connectivity solutions tend to remain unaddressed.

The present invention addresses these limitations of the prior computingsystems.

SUMMARY

In accordance with the present disclosure, the above and other problemsare solved by providing a method, apparatus, and article of manufacturefor providing a thin client for providing secure access to network-basedservices from a computing system attached to a generally unsecurednetwork. Various aspects of this thin client, and systems enabling thinclient access to such services, for example web based services, aredisclosed as well.

In a first aspect, a method for operating a remote desktop client from acomputing system hosting a secure boot device is disclosed. The methodcomprising: initiating execution of an operating system from thecomputing system hosting the secure boot device, the computing systemcommunicatively connected within a secure enterprise network, thecomputing system being untrusted within the secure enterprise network;receiving authentication credentials from the user, based onverification of the received authentication credentials, booting, fromthe secure boot device, the operating system; establishing a securecommunication tunnel with a service appliance; receiving, from theservice appliance, via the secure communication tunnel, a destinationaddress of a secure gateway device connected to the enterprise networkand community of interest keys and filters based on the authenticatedcredentials; and establishing a cleartext communication channel with thesecure gateway device, thereby allowing communication between thecomputing system and one or more trusted endpoints within the secureenterprise network.

In a second aspect, a computing system configured to communicate withtrusted endpoints within a secure enterprise network, the computingsystem being communicatively connected within the secure enterprisenetwork but untrusted within the secure enterprise network is disclosed.The computing system comprising: a programmable circuit; a memorycommunicatively connected to the programmable circuit, the memorystoring computer-executable instructions which, when executed by theprogrammable circuit, cause the computing system to perform a methodcomprising: initiating execution of an operating system from thecomputing system hosting the secure boot device, the computing systemcommunicatively connected within a secure enterprise network, thecomputing system being untrusted within the secure enterprise network;receiving authentication credentials from the user, based onverification of the received authentication credentials, booting, fromthe secure boot device, the operating system; establishing a securecommunication tunnel with a service appliance; receiving, from theservice appliance, via the secure communication tunnel, a destinationaddress of a secure gateway device connected to the enterprise networkand community of interest keys and filters based on the authenticatedcredentials; and establishing a cleartext communication channel with thesecure gateway device, thereby allowing communication between thecomputing system and one or more trusted endpoints within the secureenterprise network.

In a third aspect, a secure system for operating a remote desktop clientfrom a secure boot device positioned within a secure enterprise networkis disclosed. The method comprising: a client computer having a secureboot device connected thereto, the client computer communicativelyconnected within a secure enterprise network, the client computer beinguntrusted within the secure enterprise network; a remote servercommunicatively connected to the client computer via a communicationsnetwork; and a trusted set of processing modules stored in the secureboot device that, when executed on the client computer, cause the clientcomputer to: initiate an operating system from the secure boot device;receive authentication credentials including a user identification and apassword; based on authentication of the received credentials, boot,from the secure boot device, the operating system; establish a securecommunication tunnel with a service appliance; receive, from the serviceappliance, via the secure communication tunnel, a destination address ofa secure gateway device connected to the enterprise network andcommunity of interest keys and filters based on the authenticatedcredentials; and establish a cleartext communication channel with thesecure gateway device, thereby allowing communication between the clientcomputer and one or more trusted endpoints within the secure enterprisenetwork.

In some additional aspects, a utility of the present disclosure is that,among other aspects, it provides a method for securely connecting aclient computer, such as one having a secure boot device to a remoteserver over a communications network. The method boots a client computerfrom a trusted set of processing modules stored in the secure bootdevice, verifies the contents of the trusted set of processing modulesprior to execution of these processing modules, provides authenticationinformation from data stored upon the secure boot device to anauthorization server to establish a secure connection to another server,such as a web services server. In some aspects, the method establishesthe secure connection with the server using encryption keys stored onthe secure boot device, and transfers data between the client computerand the server over the secure connection to perform transactionsinitiated by a user of the client computer. Additionally, the presentdisclosure provides for control and update of software executing at aclient computing device. The server computer utilizes encryption keysassociated with a unique ID from the secure boot device. Additionally,distributed networks are provided that allow for distributed resourcemanagement, to allow customers access to private network areas thatshare resources with other customers, while also ensuring secure key andupdate management for each customer.

These and various other features as well as advantages, whichcharacterize the present disclosure, will be apparent from a reading ofthe following detailed description and a review of the associateddrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers representcorresponding parts throughout:

FIG. 1 illustrates a distributed system using according to oneembodiment of the present disclosure;

FIG. 2 shows an organization in which separate intranets able to beformed in the distributed system of FIG. 1 are consolidated into asingle interconnected infrastructure;

FIG. 3 is a chart illustrating end-users and their membership denoted byan “X” to different communities-of-interest of a small subset of anexample larger organization;

FIG. 4 illustrates an example logical computing environment in which anencryption key is used to encrypt a cryptographic data set transferredfrom a first computing device to a second computing device;

FIG. 5 illustrates a general purpose computing system for use inimplementing as one or more computing embodiments of the presentdisclosure;

FIG. 6 illustrates an example communications infrastructure useablewithin a computing environment to manage secure and clear textcommunications, according to various aspects of the present disclosure;

FIG. 7 illustrates an exemplary method for securely transmitting acryptographic data set among logically partitioned data paths;

FIG. 8 illustrates an exemplary method for securely transmitting amessage among logically partitioned data paths;

FIG. 9 illustrates an overall logical flow of how an original packet iscontaining a cryptographic data set, or message, is concatenated withpreheader and then split into portions which are appended with an IPheader containing a value indicating which set of data the portionbelongs;

FIG. 10 illustrates a distributed system using a secure boot deviceaccording to another embodiment of the present disclosure;

FIG. 11A illustrates a set of processing modules stored on a secure bootdevice according to yet another embodiment of the present disclosure;

FIG. 11B illustrates an example arrangement of memory of a secure bootdevice for storing the set of trusted modules on the secure boot deviceof FIG. 10;

FIG. 12 illustrates a flowchart of a method for using a secure bootdevice to create a secure connection to a server according to anembodiment of the present disclosure;

FIG. 13 illustrates a distributed processing system useable inconnection with a secure boot device to create a secure connection to aserver according to a possible embodiment of the present disclosure;

FIG. 14 illustrates a distributed processing system useable inconnection with a secure boot device to create a secure connection to aserver according to a further possible embodiment of the presentdisclosure;

FIG. 15 illustrates a distributed processing system useable inconnection with a secure boot device to create a secure connection to aserver according to a further possible embodiment of the presentdisclosure;

FIG. 16 illustrates a flowchart of creating a secure connectionaccording to an embodiment of the present disclosure;

FIG. 17 illustrates an example network in which secure tunnels cancoexist with clear text communication, according to a possibleembodiment of the present disclosure;

FIG. 18 illustrates a distributed system in which secure tunnels coexistwith clear text communication, according to a possible embodiment of thepresent disclosure;

FIG. 19 illustrates a distributed hybrid system using virtual privatenetwork and secure connections, using the distributed systems of FIGS.18-19, according to a possible embodiment of the present disclosure;

FIG. 20 illustrates a flowchart of authenticating a system for use ofcoexisting secure and clear text tunnels, according to a possibleembodiment of the present disclosure;

FIG. 21 illustrates a flowchart of methods and systems for configuring adistributed system including coexisting secure and clear text tunnelsusing a provisioning utility, according to a possible embodiment of thepresent disclosure;

FIG. 22 illustrates an example distributed system in which a secureterminal can be updated during secure connection to a customer virtualnetwork, according to a possible embodiment of the present disclosure;

FIG. 23 illustrates a second example distributed system in which asecure terminal can be updated during secure connection to a customervirtual network, according to a possible embodiment of the presentdisclosure;

FIG. 24 illustrates a third example distributed system in which a secureterminal can be updated during secure connection to a customer virtualnetwork, according to a possible embodiment of the present disclosure;

FIG. 25 is a flowchart of methods and systems for updating a securevirtual terminal connected to a distributed system, according to apossible embodiment of the present disclosure;

FIG. 26 is a flowchart of an example method for switching languages of aremote desktop client operating on a secure boot device;

FIG. 27 is an example screenshot of a desktop running on the remotedesktop client in a first language;

FIG. 28 is an example screenshot of a desktop having a toolbar forswitching languages of a remote desktop client;

FIG. 29 is an example screenshot of a desktop operating system runningon the remote desktop client in a second language;

FIG. 30 is a flowchart of an example method for switching brandings of aremote desktop client operating on a secure boot device;

FIG. 31 is an example screenshot of a desktop running on the remotedesktop client in a first branding;

FIG. 32 is an example screenshot of a desktop having a toolbar forswitching brandings of a user;

FIG. 33 is an example screenshot of a desktop operating system runningon the remote desktop client in a selected second branding;

FIG. 34 is a flowchart of an example method for operating a remotedesktop client from a secure boot device communicatively connected to asecure enterprise network;

FIG. 35 is an example distributed system of a remote desktop clientpositioned within an enterprise network;

FIG. 36 is an example distributed system of a remote desktop clientpositioned within an enterprise network;

FIG. 37 is an example distributed system of a remote desktop clientpositioned within an enterprise network; and

FIG. 38 is an example distributed system of a remote desktop clientpositioned within an enterprise network.

DETAILED DESCRIPTION

Various embodiments of the present invention will be described in detailwith reference to the drawings, wherein like reference numeralsrepresent like parts and assemblies throughout the several views.Reference to various embodiments does not limit the scope of theinvention, which is limited only by the scope of the claims attachedhereto. Additionally, any examples set forth in this specification arenot intended to be limiting and merely set forth some of the manypossible embodiments for the claimed invention.

In general, the present disclosure relates to a method, apparatus, andarticle of manufacture for providing a secure client for providingsecure access to a remote server from a computing system attached to anunsecured network. The present disclosure provides for a secureconnection to such a server generally, and in particular distributednetwork resources. Various aspects include methods and systems forsecure connection to a distributed system for performing transactions,for example using a thin client, terminal-based system. Methods andsystems for updating such a system while a secure connection isestablished are provided as well. Additionally, methods and systems formanaging encryption keys within a secure network, and for allowingsecure and clear text connections to coexist within a secure network areprovided as well.

I. Generalized Infrastructure for Secure Communication

FIG. 1 illustrates a distributed system 100 in which aspects of thepresent disclosure can be implemented, according to one embodiment ofthe present disclosure. A distributed computing system 100 allows anumber of users to communicate with any number of servers 111-113 usingtheir own client computers 121-124, via a network, show as the internet126. On a client computer 123, a web page 131 or othernetwork-accessible resource can be displayed to a user that correspondsto a transaction 132 being performed on a particular server, e.g.,server 112. The communications between the client computer 123 andserver 112 occurs over a secure connection.

In one possible embodiment of the present invention, this secureconnection utilizes a security technology developed by the UnisysCorporation that are described in detail in a number of commonlyassigned U.S. patent applications. These applications generally describea cryptographic splitting and recombining arrangement referred to hereinas “cryptographically secure” or “Stealth-enabled”. These applicationsinclude:

-   1. U.S. Provisional Application entitled: Distributed Security on    Multiple Independent Networks using Secure “Parsing” Technology, by    Robert Johnson, attorney Docket No. TN400.P, Ser. No. 60/648,531,    filed 31 Jan. 2005;-   2. U.S. Application entitled: Integrated Multi-Level Security    System, by Robert Johnson, Attorney Docket No. TN400.U.S. Ser. No.    11/339,974 filed 26 Jan. 2006 claiming the benefit of the above    provisional applications;-   3. U.S. Application entitled: Integrated Multi-Level Security    System, by Robert Johnson et al., Attorney Docket No. TN400.USCIP1,    Ser. No. 11/714,590 filed 6 Mar. 2007 which is a    continuation-in-part of U.S. application Ser. No. 11/339,974;-   4. U.S. Application entitled: Integrated Multi-Level Security    System, by Robert Johnson et al., Attorney Docket No. TN400.USCIP2,    Ser. No. 11/714,666 filed 6 Mar. 2007 which is a    continuation-in-part of U.S. application Ser. No. 11/339,974; and-   5. U.S. Application entitled: Integrated Multi-Level Security    System, by Robert Johnson et al., Attorney Docket No. TN400.USCIP3,    Ser. No. 11/714,598 filed 6 Mar. 2007 which is a    continuation-in-part of U.S. application Ser. No. 11/339,974.

All of these applications are currently pending before the U.S. Patentand Trademark Office, are commonly assigned to the owner of the instantapplication, and are incorporated herein in their entireties.

In various embodiments of the present disclosure, the servers 111-113can be distributed across a plurality of discrete locations orcontrolled by different entities; in such embodiments, these servers111-113 can be referred to generally as remote servers, as theyrepresent servers accessible from a remote location and which can beaccessed via an unsecured network. For example, in some embodiments ofthe present disclosure (discussed in greater detail below), one or moreof the servers 111-113 is a banking server, configured to communicatesecurely with one or more client terminal devices across a secureconnection, formed for example via the Internet. In such examples, orothers where a high level of security is required, one or more secureconnections can be established between client devices and a server, oramong servers, on such an unsecured network. Other serverfunctionalities or arrangements are possible as well, for exampleincluding administration, provisioning, and usermanagement/authentication systems. In such embodiments, one or more suchseparate functionalities can be integrated into, or can reside separatefrom, an entity requiring highly secure communications such as afinancial institution where reliable security is needed.

FIG. 2 shows an organization 200 in which separate intranets able to beformed in the distributed system of FIG. 1 are consolidated into asingle interconnected infrastructure. In the organization 200 as shown,a variety of physically separated resources, illustrated as residing atsites 204, 206, 208, respectively, can be communicativelyinterconnected, for example via the Internet 202. In accordance with thepresent disclosure, secure communication can be accomplished among thevarious sites 204-208, and from remote users to one or more sites. Forexample, one or more of the servers 111-113 can be physically located ata different location from other servers, and client computers 121-124can be located at any location either within an entity's intranet orexternal to that intranet. Access to the resources of the organization200 by a user is provided not based on that user's location, but his/hermembership in a community-of-interest associated with that entity.

As used in the present disclosure, a community-of-interest refersgenerally to a group of two or more people who share a common interestand are grouped together based on their common interest. Acommunity-of-interest may correspond to a role of an individual in anorganization, a job level, security level, or may correspond to someother characteristic. A community-of-interest may also correspond tosome subject defined by an organization or an individual and associatedwith one or more individuals (i.e., end-users of a computing device). Acommunity-of-interest may be defined differently depending on theorganizational structure of the entity.

FIG. 3 is a chart 300 illustrating end-users and their membershipdenoted by an “X” to different communities-of-interest of a small subsetof an example organization. In this condensed example, a President of anorganization, given his/her position, is entitled to access data in allof the communities-of-interest. On the other hand, a Payroll Specialistwhose role may be limited to only issuing paychecks can only view orshare data associated with the payroll community-of-interest and noother communities-of-interest. An HR (Human Resources) Manager givenhis/her position in HR as well as being a manager may view or share datafrom both the HR and Management communities-of-interest. Finally, inthis example, a Sales Associate is only able to view data from or sharedata with others associated with the Sales community-of-interest.

In the example shown, while the President can access data in all fourcommunities-of-interest, the President cannot share data with thePayroll Specialist if the data the President sends to the PayrollSpecialist is encrypted for use in a community-of-interest that thePayroll Specialist cannot access. That is, no communication session canbe established between the President and the Payroll Specialist otherthan within the Payroll community-of-interest. Therefore the messagewith a community-of-interest key not associated with the PayrollSpecialist cannot be sent to the Payroll Specialist. Even if the messageis accidentally received by the Payroll Specialist, the PayrollSpecialist cannot view the message, for example due to use of encryptionkeys specific to each community of interest, as discussed in furtherdetail below. This safeguard prevents inadvertent ormalicious/intentional dissemination of plaintext data to individuals whoare not members of a particular community-of-interest, and therefore,are not authorized to receive such information.

It is possible to distribute community-of-interest specific encryptionkeys (also known herein as “community-of-interest keys”) withindepartments, groups, agencies, different offices of an entity, based onranks of individuals, security level ratings of individuals,commercial/non-commercial entities, governmental/non-governmentalentities, corporations, or just about any group. It is also possible todynamically create a community-of-interest or revoke a community ofinterest by the dissemination or removal of community-of-interest keys.

Thus, in accordance with one embodiment, each individual (or end user)associated with an organization has one or more community-of-interestkeys provided on their computers, which is a secret encryption and/ordecryption key previously installed thereon as a set of code or logic ona computer. Only computer devices with matching community-of-interestkeys can communicate with one another, or observe data classified withintheir community-of-interest. That is, each community-of-interest key isassociated with an end-user's community-of-interest (such as a positionin a company or a security level), thereby allowing only end-userswithin the same group and having at least the same community-of-interestkey to communicate with each other, or to gain access to data associatedwith that community-of-interest.

Of course, multiple community-of-interest keys can be distributed toindividuals based on their membership and roles. It is conceivable thatselect end-users in each community-of-interest, may have more access tocertain data, while others may have less ability to view or share data.The methods of this invention using communities-of-interest keys allowsfor the sharing or accessing of data to end-users whose computers havebeen preconfigured with appropriate community-of-interest keys.

Community-of-interest keys may also be installed on servers or otherplatforms within a network to protect sensitive data. Servers dedicatedto a particular community-of-interest may only communicate withcomputing devices that have the same requisite community-of-interestkeys installed therein. Otherwise no communication session can beestablished between a computing device and a server without both deviceshaving the requisite key(s). Details regarding particularimplementations in which a user device connects to server systems basedon shared community-of-interest keys are described below.

Referring now to FIGS. 4-6, various components of a computing device aredisclosed, with which aspects of the present disclosure can beimplemented. With reference to FIGS. 4-5, exemplary physical and logicalorganizations of systems are shown in which aspects of the presentdisclosure can be implemented. Although some of the discussion belowwill focus on end-user equipment such as personal computers, theapplicability of the present invention is not limited to end-userequipment, and may be used with other computing devices within anetwork. For example, computing devices according to the presentdisclosure may be other general or special purpose computing devices,such as, but not limited to, gateways, servers, routers, workstations,mobile devices (e.g., POA, cellular phone, etc.), and a combination ofany of the above example devices, and other suitable intelligentdevices.

FIG. 4 is a block diagram illustrating an example computing device 400,which can be used to implement aspects of the present disclosure, andupon which one or more of the server applications, operating systems, orauthentication systems described herein can be executed. Generally, FIG.4 illustrates an example physical system useable for implementingfeatures of the present disclosure include a general-purpose computingdevice in the form of a conventional personal computer.

In the example of FIG. 4, the computing device 400 includes a memory402, a processing system 404, a secondary storage device 406, a networkinterface card 408, a video interface 410, a display unit 412, anexternal component interface 414, and a communications medium 416. Thememory 402 includes one or more computer storage media capable ofstoring data and/or instructions. In different embodiments, the memory402 is implemented in different ways. For example, the memory 402 can beimplemented using various types of computer storage media.

The processing system 404 includes one or more processing units. Aprocessing unit is a physical device or article of manufacturecomprising one or more integrated circuits that selectively executesoftware instructions. In various embodiments, the processing system 404is implemented in various ways. For example, the processing system 404can be implemented as one or more processing cores. In another example,the processing system 404 can include one or more separatemicroprocessors. In yet another example embodiment, the processingsystem 404 can include an application-specific integrated circuit (ASIC)that provides specific functionality. In yet another example, theprocessing system 404 provides specific functionality by using an ASICand by executing computer-executable instructions.

The secondary storage device 406 includes one or more computer storagemedia. The secondary storage device 406 stores data and softwareinstructions not directly accessible by the processing system 404. Inother words, the processing system 404 performs an I/O operation toretrieve data and/or software instructions from the secondary storagedevice 406. In various embodiments, the secondary storage device 406includes various types of computer storage media. For example, thesecondary storage device 406 can include one or more magnetic disks,magnetic tape drives, optical discs, solid state memory devices, and/orother types of computer storage media.

The network interface card 408 enables the computing device 400 to senddata to and receive data from a communication network. In differentembodiments, the network interface card 408 is implemented in differentways. For example, the network interface card 408 can be implemented asan Ethernet interface, a token-ring network interface, a fiber opticnetwork interface, a wireless network interface (e.g., WiFi, WiMax,etc.), or another type of network interface.

The video interface 410 enables the computing device 400 to output videoinformation to the display unit 412. The display unit 412 can be varioustypes of devices for displaying video information, such as a cathode-raytube display, an LCD display panel, a plasma screen display panel, atouch-sensitive display panel, an LED screen, or a projector. The videointerface 410 can communicate with the display unit 412 in various ways,such as via a Universal Serial Bus (USB) connector, a VGA connector, adigital visual interface (DVI) connector, an S-Video connector, aHigh-Definition Multimedia Interface (HDMI) interface, or a DisplayPortconnector.

The external component interface 414 enables the computing device 400 tocommunicate with external devices. For example, the external componentinterface 414 can be a USB interface, a FireWire interface, a serialport interface, a parallel port interface, a PS/2 interface, and/oranother type of interface that enables the computing device 400 tocommunicate with external devices. In various embodiments, the externalcomponent interface 414 enables the computing device 400 to communicatewith various external components, such as external storage devices,input devices, speakers, modems, media player docks, other computingdevices, scanners, digital cameras, and fingerprint readers.

The communications medium 416 facilitates communication among thehardware components of the computing device 400. In the example of FIG.4, the communications medium 416 facilitates communication among thememory 402, the processing system 404, the secondary storage device 406,the network interface card 408, the video interface 410, and theexternal component interface 414. The communications medium 416 can beimplemented in various ways. For example, the communications medium 416can include a PCI bus, a PCI Express bus, an accelerated graphics port(AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, aparallel ATA interconnect, a Fiber Channel interconnect, a USB bus, aSmall Computing system Interface (SCSI) interface, or another type ofcommunications medium.

The memory 402 stores various types of data and/or softwareinstructions. For instance, in the example of FIG. 4, the memory 402stores a Basic Input/Output System (BIOS) 418 and an operating system420. The BIOS 418 includes a set of computer-executable instructionsthat, when executed by the processing system 404, cause the computingdevice 400 to boot up. The operating system 420 includes a set ofcomputer-executable instructions that, when executed by the processingsystem 404, cause the computing device 400 to provide an operatingsystem that coordinates the activities and sharing of resources of thecomputing device 400. Furthermore, the memory 402 stores applicationsoftware 422. The application software 422 includes computer-executableinstructions, that when executed by the processing system 404, cause thecomputing device 400 to provide one or more applications. The memory 402also stores program data 424. The program data 424 is data used byprograms that execute on the computing device 400.

The term computer readable media as used herein may include computerstorage media and communication media. As used in this document, acomputer storage medium is a device or article of manufacture thatstores data and/or computer-executable instructions. Computer storagemedia may include volatile and nonvolatile, removable and non-removabledevices or articles of manufacture implemented in any method ortechnology for storage of information, such as computer readableinstructions, data structures, program modules, or other data. By way ofexample, and not limitation, computer storage media may include dynamicrandom access memory (DRAM), double data rate synchronous dynamic randomaccess memory (DDR SDRAM), reduced latency DRAM, DDR2 SDRAM, DDR3 SDRAM,solid state memory, read-only memory (ROM), electrically-erasableprogrammable ROM, optical discs (e.g., CD-ROMs, DVDs, etc.), magneticdisks (e.g., hard disks, floppy disks, etc.), magnetic tapes, and othertypes of devices and/or articles of manufacture that store data.Communication media may be embodied by computer readable instructions,data structures, program modules, or other data in a modulated datasignal, such as a carrier wave or other transport mechanism, andincludes any information delivery media. The term “modulated datasignal” may describe a signal that has one or more characteristics setor changed in such a manner as to encode information in the signal. Byway of example, and not limitation, communication media may includewired media such as a wired network or direct-wired connection, andwireless media such as acoustic, radio frequency (RF), infrared, andother wireless media.

Additionally, the embodiments described herein are implemented aslogical operations performed by a computer. The logical operations ofthese various embodiments of the present invention are implemented (1)as a sequence of computer implemented steps or program modules runningon a computing system and/or (2) as interconnected machine modules orhardware logic within the computing system. The implementation is amatter of choice dependent on the performance requirements of thecomputing system implementing the invention. Accordingly, the logicaloperations making up the embodiments of the invention described hereincan be variously referred to as operations, steps, or modules.

FIG. 5 illustrates an example arrangement of logical components of ageneral purpose computing device 500 for use in implementing as one ormore computing embodiments of the present invention, and can beimplemented within the hardware environment including computing device400 illustrated in FIG. 4. In the embodiment shown, the computing device500 includes a controller 502 including at least one processor 504, apower source 506, and memory 508, which can be as described above inconnection with FIG. 4. In some implementations, volatile memory 510 isused as part of the computing device's cache, permitting applicationcode and/or data to be accessed quickly and executed by processor 504.Memory 508 may also include non-volatile memory 512, as well as flashmemory 514. It is also possible for other memory mediums (not shown)having various physical properties to be included as part of computingdevice 400.

A file system 522 may reside as a component in the form ofcomputer-executable instructions and/or logic within memory 508, thatwhen executed serves as a logical interface between code stored in flashmemory 514 and other storage mediums. File system 522 is generallyresponsible for performing transactions on behalf of code stored in ROMor one or more applications. File system 522 may also assist in storing,retrieving, organizing files, and performing other related tasksassociated with code and/or data. That is, file system 522 has theability to read, write, erase, and manage files (applications, etc.).File system 522 may also include other applications such as webbrowsers, e-mail, applications, and other applications.

Computing device 400 may also include one or more Input/Output ports 516to transmit and/or receive data. I/O ports 516 are typically connectedin some fashion to controller 502 (processor 504 and memory 508). I/Oports 516 are usually at least partially implemented in hardware forconnecting computing device 500 to a communication link 518, and mayinclude wired as well as wireless capabilities. Communication link 518may include any suitable connection means for handling thetransportation of data to and from computing device 500, such as, butnot limited to, cable, fiber optics, and wireless technology.Communication link 518 may also include network technology includingportions of the Internet.

Stored within one or more portions of memory 508 is a security engine550. That is, security engine 550 includes one or more sets ofcomputer-executable code resident in a computer-readable medium such asmemory 508. Security engine 550 performs security functions associatedwith transmitting, receiving, or storing data. These security functionsmay include encrypting data and decrypting data. Typically,cryptographic corresponding key pairs are installed in memory, such asan encryption key and decryption keys. However, it is appreciated that acorresponding cryptographic key may reside on another computing device.The keys may be public or private as would be appreciated by thoseskilled in the art. The keys may be generated using commerciallyavailable products or proprietary technology.

In one embodiment, security engine 550 includes one or more filters 552,which define permissions relating to secure communication by thecomputing device 500. By permissions, it is intended that one or moreremote endpoints can be defined in a filter, and access to that endpointcan be either allowed or prevented based on an identity of a user.

In such an embodiment, security engine 550 also includes one or morecommunity-of-interest keys 554, which are private and secret keys usedfor encrypting/decrypting other security keys in accordance with thisinvention. That is, community-of-interest keys 554 are used fortransformation (encryption) of a second key (or additional keys), suchas a session key, into a cryptographically split key, as well as forretransformation (decryption) of the second key back to its usable form.

A community-of-interest key 554 refers generally to an encryption keyand/or corresponding decryption key, that may be assigned to a computingdevice 500 of an end-user based on an associated community-of-interestattributed to the end-user. For instance, end-users of a computingdevice 500, may also have one or more community-of-interest keys 554installed on their computing device, based on their position or securitylevel within an organization.

It is also possible to secure and segregate messages based on a categoryof a community-of-interest associated with the message using acorresponding community-of-interest key 554 (e.g., cryptographic pairs).Also, unlike private/public key pairs, community-of-interest keys 554are usually installed or generated before a transaction to increasesecurity, rather than receiving and generating the key on-the-fly duringa transaction, in which the key can be intercepted.Community-of-interest keys 554 may be stored in a key repository 566,which is a storage area in memory 508. Filters 552 can also be stored inmemory 508.

In some embodiments, each community-of-interest key 554 has anassociated filter 552, such that a set of endpoint access permissionsare included with each community of interest. In such embodiments, thefilter associated with a community-of-interest key 554. Examplecommunity of interest keys can include a secure community of interestkey 554, that may have an associated filter defining one or moreendpoints and/or gateway devices associated with that community ofinterest and excluding communication with any unsecured sites, or aclear text filter that would allow clear text communication withexternal, publicly available and unsecured systems (e.g., via theinternet). In the example of the clear text filter, such a filter couldinclude one or more exclusionary permissions preventing clear textcommunication to secured endpoints or gateway devices normally requiringcryptographically-secured communication. Additional details regardingexample key and filter arrangements are discussed below in conjunctionwith FIGS. 17-21.

Security engine 550 may also include a cryptographic engine 556 forgenerating cryptographic keys and other information used to encrypt ordecrypt messages, as well as route data to a target device. In oneembodiment, cryptographic engine 556 generates a cryptographic data set,which may include one or more session keys which are used forencrypting/decrypting one message or a group of messages when computingdevice 500 is in a communication session with another device.

Security engine 550 may also include other authentication data and code558, used for purposes of authenticating data or information, such aspasswords, recorded biometric information, digital certificates, andother security information. As is appreciated by those skilled in theart after having the benefit of this disclosure, it is possible thatthere may be various combinations of keys and authentication data insecurity engine 550.

Although described in terms of code, the exemplary security engine 550may be implemented in hardware, software, or combinations of hardwareand software. Additionally, all components of security engine 550 may becommunicatively coupled to each other through controller 502. As wouldbe appreciated by those skilled in the art, many of the components ofsecurity engine 550 may be stored and identified as files under controlof file system 522.

Security engine 550 may also include a data splitter module 560 forsplitting data that is to be transmitted from computing device 500.Typically, security engine 550 relies on a community-of-interest keyand/or cryptographic engine 556 to determine how to split and encryptdata. Data splitter module 560 divides data into portions of data. Aportion of data is any bit or combination of bits of data that comprisea larger set of data, such as a message or a portion of a cryptographicdata set (a second key). A portion of data may be encapsulated inpackets for transport, but the content of the data may be fixed or of avariable bit length. Accordingly, a portion of data (such as a portionof message or portion of cryptographic data set) corresponds to one ormore bits comprising data content, i.e., payload as opposed to a dataheader message. Data splitter module 560 may be configured to producepredetermined bit length portions of data or it may be determineddynamically in an automatic fashion.

Security engine 550 may also include an assignment module 562.Assignment module 562 assigns tags to each portion of data (portion of amessage or key). Each tag contains metadata indicating a traffic path(to be described) a particular portion of data is to be distributedthrough one or more networks to another computing device 400. Othermetadata may be included in the tags, such as information identifyingthe network the portion of data originated, the client devicedestination, possibly the order of the portion of data in relation toother portions of data emitted from the same network, and other suitableinformation.

Security engine 550 may also include an assembler module 564 configuredto reassemble portions of data received at different times, and/or viadifferent data paths. Once data is reassembled, authorized assets andmessages appear accessible in plaintext format from the end-usersperspective. It is noted that various security techniques may beemployed on computing device 500 to prevent the user from saving data,mixing different levels of data, or sending the data to other locationsfor dissemination to another network, such as via email or otherelectronic transfer means. Applications may also execute on separatephysical and/or logical partitions within computing device 500.

Additional details regarding the security engine and cryptographic datasets generated using the security engine are discussed in U.S. PatentApplications Nos. 60/648,531; 11/339,974; 11/714,590; 11/714,666; andSer. No. 11/714,598, which were previously incorporated by reference intheir entireties.

FIG. 6 illustrates an example communications infrastructure 600 useablewithin a computing environment to manage both secure and clear textcommunications channels, according to various aspects of the presentdisclosure. The communications infrastructure 600 can be implementedwithin the computing device 400, 500 of FIGS. 4-5, for example using theoperating system 420, application software 422, and program data 424 tomanaging operation of network interface or adapter 408 of FIG. 4, andfor example as at least in part implemented using security engine 550 ofFIG. 5.

In the embodiment shown, the communications infrastructure 600 includesa physical network interface card 602 communicatively interconnected toa network 604, illustrated in this embodiment as an Ethernet local areanetwork (LAN). The physical network interface card 602 is generally apiece of communications hardware included within the computing system,and can be, in one embodiment, the network interface adapter 452 of FIG.4.

The communications infrastructure 600 includes a routing table 606,which defines one or more local and remote IP addresses used tocommunicate messages between a computing system incorporating thecommunications infrastructure 600 and a remote computing system. Forexample, the routing table 606 can include a default route, localnetwork and broadcast addresses, as well as one or more network masks,gateways, and other points of interest.

In general, when a computing system intends to transmit clear text datausing the physical network interface card 602, that system willdetermine an address using the routing table 606 and form a packet to beforwarded to the physical network interface card 602 for communicationvia network 604. In accordance with the present disclosure, to separatesecure data communications from standard clear text communications, adedicated communication stack can be used for each of one or more typesof secured communication.

In the embodiment shown, and as discussed in further detail in variousembodiments of the present disclosure below, the communicationsinfrastructure 600 includes a first secure software stack 608 and asecond secure software stack 609, each useable to communicate over asecured connection to a remote system. The first secure software stack608 that includes a secure communications driver 610, a virtual securenetwork interface card 612, and a network interface card driver 614.

The secure communications driver 610 receives data to be transmitted viaa secured communication method (e.g., as described in FIGS. 7-10,below), and an address from the routing table 606, and generates one ormore packets of encrypted data to be transmitted. In some embodiments,as discussed further below, the secure communications driver uses one ormore filters to determine whether secured (split and encrypted) datapackets can be sent or received to/from a particular network address,and to determine whether secure or clear text data packets can beaccepted at the computing system implementing the communicationsinfrastructure 600. For example, if a data packet or message is receivedat the virtual secure network interface card 612 from an endpoint notincluded in an access list of a filter that defines permissions to thatendpoint or client device, the secure communications driver 610 willdiscard that packet, preventing it from reaching an application to whichit would otherwise be addressed or intended. Likewise, the securecommunications driver 610 can prevent communication of data packets toremote endpoint systems not authorized by the access lists in one ormore filters defined in the computing device.

The virtual secure network interface card 612 acts as a virtual versionof the physical network interface card 602, in that it receives datapackets formed at the secure communications driver 610 and instructionsfor where and how to transport those data packets. In certainembodiments, the secure communications driver 610 acts analogously to ahardware driver, but acts on the virtual secure network interface card612.

The network interface card driver 614 provides the link between thevirtual secure network interface card 612, and physical networkinterface card 602 to allow communication of secured data packets with aremote system (e.g., an endpoint, gateway, or other remote system). Incertain embodiments, the network interface card driver 614 acts as apiece of hardware to the operating system of the computer implementingthe communications infrastructure 600, for example to host the virtualsecure network interface card 612, and allow applications to transmitdata via that piece of virtual hardware.

In the embodiment shown, an optional second software stack 609 is alsoshown, which can be used concurrently with the first secure softwarestack 608. In the embodiment shown, the second software stack isconfigured to allow a different type of security, in which security isnot provided by data obfuscation on a packet-by-packet basis, but ratherby creating a secured connection to a dedicated endpoint. In the exampleembodiment shown, this second software stack 609 is configured to managecommunication via a virtual private network (VPN) connection, where asecure tunnel is formed between the computing system operating thecommunications infrastructure 600 and a predetermined, known gateway. Inthis embodiment, the second software stack 609 includes a VPN driver616, a virtual VPN network interface card 618, and a VPN communicationsdriver 620. The VPN driver 616 generates instructions for communicationwith a particular VPN gateway, and for constructing a secure tunnelbetween the computing system implementing the communicationsinfrastructure 600 and the VPN gateway (e.g., as illustrated below inconnection with FIG. 20). The virtual VPN network interface card 618,like the virtual secure network interface card 612, acts as a virtualversion of the physical network interface card 602, in that it receivesdata packets formed at the VPN driver 616 and instructions for where andhow to transport those data packets (e.g., via a secure tunnel). Thevirtual VPN network interface card 618, similar to the network interfacecard driver 614 acts as a piece of hardware to the operating system ofthe computer implementing the communications infrastructure 600, forexample to host the virtual VPN network interface card 618, and allowapplications to transmit data via that piece of virtual hardware toremote systems.

Overall, and referring to FIGS. 1-6 generally, it is noted that thecomputing systems and generalized example networks of the presentdisclosure generally provide infrastructure for receipt and managementof encryption keys specific to one or more communities-of-interest, anddistributed use of algorithms for encrypting and splitting data intoobscured data packets such that only those individuals having accessrights to that data can in fact reformulate the data upon receipt ofthose data packets. FIGS. 7-9 below briefly describe methods andarrangements for treatment of data packets sent and received from agateway, endpoint, or other computing device configured for securedcommunication using the cryptographic splitting and virtual networkarrangements of the present disclosure.

II. Methods for Secure Communication

Referring now to FIGS. 7-9, methods and systems for securelytransmitting data packets between computing systems are disclosed.Generally, the methods and systems illustrated in FIGS. 7-10 provide abrief overview of methods of handling data packets sent and receivedusing the computing systems and networks described herein, for examplethose discussed above with respect to FIGS. 1-6. Additional detailsregarding these methods and systems are disclosed in the copending U.S.Patent Applications Nos. 60/648,531; 11/339,974; 11/714,590; 11/714,666,and 11/714,598, listed above and previously incorporated by reference.

As used herein, a “message” or “data packet” refers generally to any setof data sent from one node to another node in a network. A message mayinclude different forms of data usually in some form of a payload. Amessage may be an e-mail, a video stream, pictures, text documents, wordprocessing documents, web-based content, instant messages, and variousother forms of data that when in plain text, or clear form, may revealconfidential and sensitive information. In most instances, thisinvention is concerned with securing data-in-motion, or in other words,cryptographic data or messages sent from one node to another node suchas data traveling from one location to another within one or morenetworks which may include the Internet.

FIG. 7 illustrates an exemplary method 700 for securely transmitting acryptographic data set among logically partitioned data paths. Thecryptographic data set can include, for example one or more encryptionkeys, filters, and other information useable at an endpoint or othercomputing device to enable that device to establish secure communicationwith a remote system (e.g., another endpoint, a gateway, or any otherremote device configured for cryptographically split communication).

In this method, in block 702, a cryptographic data set is divided into aplurality of portions, and tag values are assigned to each portion ofthe set. Each portion is encapsulated in separate packets. In block 704,the portions of cryptographic data set are transmitted from an egresspoint of a computing device, such as a network interface card asdiscussed above in conjunction with FIG. 6. On the receiving endpoint,in block 706, each portion of cryptographic data is received by a targetcomputing device. In one embodiment, as the packets received include anew community-of-interest key identifier embedded therein. In anotherembodiment, newly received packets do not include such a key identifier,and instead the receiving endpoint attempts to restore (reassemble) acryptographic data portion encapsulated in a payload portion of thepacket using a community-of-interest key accessed from the receivingcomputing device's repository. If there is only onecommunity-of-interest key present in the repository, the receivingcomputing will attempt to reassemble the cryptographic data portion(s)using the single key. If there are more than one community-of-interestkey in the receiving computing device's repository, the receivingcomputing device will iteratively try each key until it locates a keywhich is able to reassemble the cryptographic data portion(s).

However, if no identifier match is located in block 706, in Step 708each packet and hence portion of cryptographic data set received by thetarget device is discarded, erased, and/or ignored. This may represent asituation where the end-user of an endpoint does not have authorizationto view a message, because the end-user (or the end-user's computingdevice) lacks the requisite community-of-interest key, or if thetransmitting computing device is not included in a listing of permitteddevices at the target device.

If according to the Yes branch of block 706, a community-of-interest keymatching the identifier is located, or a community-of-interest key isidentified which is able to restore the payload portion of thepacket(s), then in block 710 each portion of the cryptographic data setis temporarily stored for eventual reassembly. At this point a tunnelcan be established between the sending and receiving computing devices.

In block 712, the cryptographic data set is decrypted. That is, thecryptographic data set is reconstructed (reassembled) by decrypting eachportion of the cryptographic data set using the community-in-interestkey identified in block 710. Once all portions of cryptographic data setare received, it is possible to fully reassemble the cryptographic dataset on the receiving computing device. The cryptographic data set is ina usable form for use to decrypt portions of a message received, whichwill be described with reference to FIG. 8.

FIG. 8 illustrates an exemplary method 800 for securely transmitting amessage among logically partitioned data paths, according to a possibleembodiment. Generally, method 800 occurs after a secure tunnel has beencreated, to allow transmission between two computing systems. Method 800includes blocks 802, 804, 806, and 808 (each of the blocks representsone or more operational acts). The order in which the method isdescribed is not to be construed as a limitation, and any number of thedescribed method blocks can be combined in any order to implement themethod. Furthermore, the method can be implemented in any suitablehardware, software, firmware, or combination thereof.

In block 802, a message is divided into portions, and tag values areassigned to each portion of the set. Each portion is encapsulated inseparate packets using a cryptographic data set at the sending computingdevice. For example, in one embodiment, an assignment module 562 (FIG.5) uses a cryptographic data set stored at the sending computing device(or as received, according to the method 700 of FIG. 7) to assign tagsto each portion of the message. Each tag contains metadata indicating atraffic path a particular portion of a message is to follow to a targetcomputing device within a network.

In block 804, the portions of cryptographic data set are transmittedfrom an egress point of a computing device. For example, portions ofcryptographic data set are transmitted from an I/O port 516 of computingdevice 500, separately. In one embodiment, transmitting the portionsseparately may include transmitting at least one portion of the messageat a different instance in time than at least another portion of themessage. In one embodiment, transmitting the portions of the messageseparately includes transmitting at least two different portions of themessage on at least two different data communication paths. For example,computing device 500 assigns a portion of message to a particular datapath based on the tag value. Tag values assigned to each portion ofcryptographic data may correspond to a particular communication datapath, to transmit the portion of cryptographic data set. In block 806,each portion of the message set is temporarily stored for eventualreassembly in some portion of memory 508 (FIG. 5) of a computing device.

In block 808, the message is put into a useable form. That is, themessage is reconstructed (reassembled) by decrypting each portion of themessage using the cryptographic data set. For example, security engine550 (FIG. 5) may use an assembler module 564 (FIG. 5) in conjunctionwith a cryptographic data set to reassemble portions of message receivedat different times, and/or via different data paths. Once all portionsof the message are received, it is possible to fully reassemble themessage in a usable form on the receiving computing device.

FIG. 9 illustrates an overall logical flow of how an original message orcryptographic data set (e.g., as in FIGS. 7-8, above) is split andencrypted according to the various embodiments discussed herein. Asillustrated, an original message 902 is combined with a preheader 904,and split into portions 906 by a splitting function 908. The splittingfunction 908 also acts to encrypt each of the portions, such that eachportion contains an obfuscated portion of the original message 902. Eachof the portions 906 are appended with an IP header 910. The IP header910 of each split portion identifies the set of data to which theportion 906 belongs. The various portions can then be passed from afirst computing system to a second computing system via a number ofdifferent routes, with the second computing system having a capabilityof reassembling that original message 902 (for example, due topossession of a complementary community-of-interest key or cryptographicdata set) at a reassembly function 912. In various embodiments, thesplitting function 908 and reassembly function 912 can be performed, forexample, by a security engine, such as security engine 550 of FIG. 5, onan authorized transmitting and receiving computing device, respectively.In certain embodiments, the splitting function 908 and reassemblyfunction 912 use a strong encryption standard, such as AES-256encryption. Other types of encryption standards and datasplitting/dispersal operations could be used as well.

III. Transaction Security Using a Secure Boot Device

Referring now to FIGS. 10-16, a particular embodiment of the distributedsystems discussed above is disclosed in which a secure connection can beestablished across a public network, such as the internet. In thisembodiment, generally a secure boot device can be used to create asecure environment at an otherwise untrusted computing device, which canin turn remotely access a trusted computing device. Such an embodimentcan be used, for example, to provide a secure portal to a centralizedtransaction processor, such as a banking institution, a governmentalinstitution, or other entity where in-transit data security isimportant.

Referring now specifically to FIG. 10, a generalized example of adistributed system 1000 is shown, using a secure boot device 1002,according to a possible embodiment of the present disclosure. In theembodiment shown, the distributed system 1000 includes a server 1004,such as a banking or government server. The distributed system alsoincludes one or more remote computer systems 1006, for examplecustomer-owned, employee-owned, or otherwise uncontrolled systems. Theserver 1004 can be any of a number of types of server systems capable ofreceiving transactions from the one or more remote computer systems1006, such as a web server or database server. In alternativeembodiments include more than one server and/or computer system 1006.

In certain embodiments, a client computer system 1006, also referred toherein as an endpoint or client computing device, can display a userinterface, such as web page 1008. The web page 1008 or other userinterface can display to a user details of a transaction 1005 takingplace at the server 1004, for example a financial transaction in thecase that the server 1004 is a banking server, or some other type oftransaction relating to an entity for which highly secure communicationsare desired. A secure connection 1010 is created between the clientcomputer system 1006 and the server 1004 to allow transmission ofdetails regarding the transaction over a public network, such as theinternet.

In order to create the secure connection 1010 in a form that may betrusted by the server 1004, in certain embodiments the client computersystem 1006 boots an operating system that is stored on a secure bootdevice 1002 attached to the client computer system 1006. This secureboot device 1002 stores a trusted version of operating system softwareand secure communications software used when the client computer system1006 establishes and performs the communications with the server 1004.In one embodiment, the secure boot device 1002 may correspond to a USBstorage device such as a Stealth M500™ from MXI Security. A copy of thedatasheet for the MXY M500 device is submitted alongside thisapplication, and incorporated by reference herein in its entirety. Insuch embodiments, the client computer system 1006 is a USB-bootablecomputing system capable of communication with a remote system, such asserver 1004, or a gateway providing access to the server havingcapabilities of communicating using the cryptographic splittingoperations discussed herein.

The secure boot device 1002 provides secure storage that preventstampering with the software loaded onto the device. This secure storagepermits the institution operating the server 1004, such as a bank orother financial institution, to load onto the secure storage a set oftrusted software modules that may limit the possible operations that aclient computer system 1006 may perform. For example, the softwaremodules can be configured to prevent the client computer system 1006from accessing non-secured network resources, and can limit otherperipheral communication channels (e.g., Bluetooth, serial connections,or other peripheral device connections), as well as prevent the clientcomputer system 1006 from executing application programs stored in amemory of the system itself. As such, the transactions 1005 may betrusted by both the user at the client computer system 1006, and theinstitution controlling the server 1004. In addition, the establishmentof the secure connection 1010 between the client computer system 1006and the server 1004 may be authenticated using identificationinformation stored upon the secure storage (e.g., acommunity-of-interest key) to increase the level of trust that the usercorresponds to a customer of the bank.

FIG. 11A illustrates a set of processing modules 1100 stored on a secureboot device 1002 according to yet another embodiment of the presentinvention. The set of processing modules 1100 are preferably stored in aread-write portion of memory of a secure boot device that can, forexample, be updated by a trusted network resource, as discussed below.When a user wishes to establish a secure connection 1010 to a server1004 using a client computer system 1006, the user boots the clientcomputer system 1006 from the secure boot device 1002. To ensure thatthe client computer system 1006 poses a minimized threat of harm to theserver 1004, a minimal set of software modules 1101-1104 are loaded whenthe client computer system 1006 boots from the secure boot device 1002.This minimal set of software modules include boot software 1101, aclient terminal process module 1102, a small OS shell 1103 and securecommunications interface software module 1104. Other modules could beincluded as well.

In some embodiments, each of these modules 1101-1104 are read from asecure boot image 1106 on the secure boot device 1002 at boot time ofthe client computer system 1006. These modules 1101-1104 are storedwithin the RAM of the client computer system 1006 and executed while theuser communicates with the server 1004. Although in some embodiments,modules 1101-1104 can be located in a read-only portion of memory of thesecure boot device 1002 and loaded from that location when the clientcomputer system 1006 is booted from the secure boot device, in otherembodiments, the modules 1101-1104 are stored in a read-write memory,allowing the modules 1101-1104 to be updated in parallel with executionfrom copies of the modules stored in RAM on the client computer system1006. Details regarding this feature are described in greater detailbelow.

The boot software 1101 comprises the software modules needed to load theother software modules into the RAM of the client computer system 1006.This module ensures that the secure boot image is a valid image beforethe modules are loaded. It may perform consistency checks to verify thatthe modules have not been modified prior to loading and use.

The client terminal process module 1102 comprises the process thatprovides a user interface to the user of the client computer system 1006as well as communications to the server 1004. In various embodiments ofthe present disclosure, the client terminal process module 1102 createsa communications session, accepts commands and inputs from the user, andinteracts with remote resources, such as web services or other datacommunication services, on the server 1004 to permit the user to performtransactions 1005. In various embodiments, this process may include aweb browser or other file access mechanism for interaction with a serverusing known Internet based protocols. In other embodiments, the clientterminal process module 1102 may be a specialized client applicationthat performs similar communications and user controls. The clientterminal process module 1102 may limit a user's ability to inputdestination URLs and related server addresses into a browser, therebyallowing only use of one or more addresses preloaded into the secureboot device 1002 as an example additional mechanism to enhance security.

The small OS shell 1103 comprises a stripped down version of a standardoperating system such as Linux™. For example, the small OS shell 1103can in some embodiments include only the supporting modules and driversnecessary to support the client terminal process module 1102 and thecommunications interface module 1104 used to establish and utilize thesecure connection 1010 to the server 1004. All other modules thattypically are included in an operating system to permit the generalpurpose use of the client computer system 1006 as well as to initiatethe execution of any program stored on the client computer system 1006can be omitted. In one embodiment, the client terminal process module1102 will begin execution at the end of the boot process, and thusprovide the only means by which the user may use the client computersystem 1006 during its operation.

The communications interface software modules 1104 performs the securecommunications with between the client computer system 1006 and theserver 1004 and any security related processing. This may include, forexample, encryption and parsing as defined in the previously identifiedpatent applications that have been incorporated herein. This module mayalso be involved in the authentication of the client computer system1006 to the server 1004 as well as its current operation in a secure andtrusted state after having booted from the secure boot device 1002.

FIG. 11B illustrates storage and management of one or more processingmodules, such as modules 1101-1104, on the secure boot device 1002. Inthe embodiment shown, the secure boot device includes a read/writememory 1120 and a read-only memory 1140. The read/write memory 1120includes an open read/write portion 1122 and a dedicated read/writeportion 1124. In certain embodiments, the open read/write portion 1122,the dedicated read/write portion 1124, and the read-only memory 1140 areviewable to a user of a computing device as separate logical memoryspaces (e.g., separate drives); however, in other embodiments, thesepartitions could be considered separate directories or otherwiselogically distinct.

The open read/write portion 1122 generally is useable by a user to storeunsecured files, such as documents or files retrieved from websites bythat user while using the secure boot device. In some embodiments, theopen read/write portion 1122 is accessible for storage only when thesecure boot device 1002 is used to boot a computing system to which itis connected; in other embodiments, the open read/write portion 1122operates as a traditional storage device when the secure boot device1002 is inserted into such a computing system.

The dedicated read/write portion 1124 includes a plurality of softwaremodule storage areas in which different types of software can be stored.In the embodiment shown, the dedicated read/write portion 1124 includesa runtime content area 1126, a custom content area 1128, and first andsecond thin client operating system areas 1130, 1132. In alternativeembodiments, other storage areas could be used as well. Additionally, inthe embodiment shown, the dedicated read/write portion 1124 can besecured using a private partition key which can be used to decrypt thedata in the dedicated read/write portion 1124 upon receipt of a PIN orother credential.

In the embodiment shown, the runtime content area 1126 storesconfiguration information used locally on the secure boot device toindicate a configuration of the local device to be used when a computingsystem is launched using the secure boot device. In certain embodiments,the runtime content area is password protected, preventing anunauthorized user of the secure boot device 1002 from accessing thisconfiguration information, or rebooting a computing system using thesecure boot device.

The custom content area 1128 stores specific provisioning information,for example a location of a secure server to connect to, as well asvarious options for connection. The custom content area 1128 can alsooptionally store branding information, for example to indicate theparticular customer or entity distributing the secure boot device 1002to its employee or affiliate.

A first thin client operating system area 1130 can store a thin clientversion of an operating system, as well as one or more applicationscapable of running on that operating system. In some embodiments, thefirst thin client operating system area 1130 stores an embedded versionof an operating system, such as Windows XP Embedded, from MicrosoftCorporation of Redmond, Wash. Other embedded operating systems could beused as well. In some embodiments, the first thin client operatingsystem area 1130 also stores other application data, such as could beused to access remote websites or other remotely networked resources.One example of such an application is an Internet Explorer web browserprovided by Microsoft Corporation of Redmond, Wash. Other applicationscould be included as well.

The second thin client operating system area 1132 stores a second thinclient version of an operating system applications capable of running onthat operating system, as well as optionally one or more securitymodules configured to provide application-level access to securityfeatures useable on a computing system booted from a secure boot device1002. In this embodiment, the second thin client operating system area1132 can store, for example, an open source thin client operating system(e.g., Linux-based), as well as virtualization software, remote desktopsoftware, and browser software (e.g., Firefox or Chrome web browsers).The second thin client operating system area 1132 can also optionallystore one or more security applications allowing a user to control thesecure connection established with a remote server. For example, thesecond thin client operating system area 1132 can include Stealthapplications and driver software, as well as a remote update agentconfigured to manage updating of software on the secure boot device 1002in accordance with the methods and systems described below inconjunction with FIGS. 22-25.

The read-only memory 1140 stores one or more utilities intended to beused to establish secure connections, such as libraries and utilitiesconfigured to establish a cryptographically split connection with one ormore servers. In certain embodiments, the read-only memory 1140 storesan operating system kernel useable with thin client operating systemsoftware stored in the second thin client operating system area 1132.Additionally, in the embodiment shown, the read-only memory 1140 can besecured using a private partition key which can be used to decrypt thedata in the read-only memory 1140 upon receipt of a PIN or othercredential.

In some embodiments, in particular those described below in which updateof the secure boot device 1002 is performed, the dedicated read/writeportion 1124 also includes a replacement area 1150 for one or moreportions of the software stored therein. In the embodiment shown, areplacement custom content area 1128, and first and second thin clientoperating system areas 1130, 1132 are shown. In such embodiments, theseportions can be updated from a remote system, such as a remote updateserver or update enclave. Update agent software stored in the secondthin client operating system area 1132 can be used to track the statusof an update, such that the replacement software modules can besubstituted for the active software modules once fully downloaded from aremote system.

FIG. 12 illustrates a flowchart of a method 1200 for using a secure bootdevice, such as secure boot device 1002, to create a secure connectionto a server according to an embodiment of the present invention. In theembodiment shown, a four step process is used; however, in alternativeembodiments, more or fewer steps could be performed. The method 1200begins with a user suspending the operation of a client computer, suchas client computer system 1006, by halting the operation of its standardoperating system in step 1201. In one embodiment, a client computersystem 1006 typically runs a version of the Windows™ operating systemfrom the Microsoft Corporation; however, in alternative embodiments,different operating system software could be executed on the clientcomputer system 1006. Irrespective of the particular operating systemused, the operating system of the client computer system 1006 is haltedin order to permit the client computer system 1006 to reboot using thesecure boot device 1002, i.e., the small OS shell 1103.

A user attaches the secure boot device 1002 to the client computersystem 1006 and the computer is rebooted in step 1202. If the secureboot device 1002 corresponds to a USB memory stick, the device is merelyinserted into a USB port on the client computer system 1006 prior torebooting the computer. Other arrangements are possible as well,depending upon the particular format taken by the secure boot device.When the client computer system 1006 is rebooted, it is instructed touse the operating system image stored on the secure boot device 1002that causes the trusted system software to be loaded and the clientterminal process module 1102 to be executed.

In step 1203, the user provides additional information to the clientterminal process module 1102 used in the authentication process as asecure connection is established between the client computer system 1006and the server 1004. A secure connection 1010 is then established usingthe information from the secure boot device 1002. The user may now usethis secure connection 1010 in step 1204 to perform banking transactionson the server 1004. Once all of these transactions are completed, theuser may shut down the client computer system 1006 and reboot into itsstandard operating system, returning the client computer system 1006 tonormal operation. This shut down process terminates the secureconnection between the client computer system 1006 and the server 1004,restoring the functionality of the operating system normally executingon the client computer system 1006.

Referring now to FIGS. 13-15, a set of possible embodiments ofdistributed processing system using a secure boot device to create asecure connection to a server are shown. In these multiple alternateembodiments, a client computer uses the previously described processesof establishing a secure connection to a server via a wide area network(WAN) after the client computer boots from a secure boot device.Typically, the WAN connecting these computers corresponds to the publicInternet, although any communications may be used. The client computers,according to the embodiments shown, generally interact with a secureappliance to provide a trusted connection to a service provider, such asa bank, data center, or other facility or entity desiring securedcommunications. The security related operations of encryption andparsing of the data, as described within the previously identifiedpatent applications are performed in the various illustrated clientcomputers and the secure appliances.

FIG. 13 illustrates a distributed processing system 1300 useable inconnection with a secure boot device to create a secure connection to aserver according to a first of these possible embodiments. Thedistributed processing system 1300 is, in the embodiment shown, oneexample distributed, networked arrangement that can be implementedaccording to the generalized discussion in conjunction with FIGS. 10-12,above. In the embodiment shown, the distributed processing system 1300includes a pair of client locations 1302 a-b. Each client location 1302includes one or more client computing devices 1304, which can join asecured distributed processing system using secure boot devices 1306. Inthe embodiment shown, client location 1302 a includes a network addresstranslation (NAT) module 1308 and a DHCP module 1310, capable of localdomain and network address resolution at the client location 1302 a.Optionally, other client locations, such as client location 1302 b, caninclude this or other networking functionality as well.

Each of the client computing devices 1304 are configured to be capableof accessing a remote location 1312, such as a central office orinstitution hosting a resource to be accessed. In the embodiment shown,the remote location 1312 is a data center that includes an entityintranet 1314, such as a data center network or other set of resources,that is accessible via a web application 1316. Other types of remotelocation resources could be made available as well. Each of the clientcomputing devices 1304 connect to the remote location 1312 via an opennetwork, illustrated as the internet 1318.

At the remote location 1312, typically one or more access devices,illustrated as a network management system 1320, generally receivesclear text communication from the internet 1318, for example relating totypical, unsecured communication of data. This is illustrated by thesolid line extending from the cloud representing the internet 1318 tothe network management system 1320. The network management system 1320can perform a variety of operations on inbound and/or outbound data,such as packet inspection and routing, load balancing across one or morecomputing systems and/or workloads, and firewall operations.Additionally, the remote location 1312 can include one or more securegateway appliances 1322 configured to perform cryptographic splittingand encrypting operations, to allow for secured communication withclient computing devices 1304 via a WAN, e.g., the internet 1318(illustrated by broken line connections). The secure gateway appliances1322 can receive the split and encrypted data at via the internet 1318,recompose that data into original, clear text data, and forward it toother portions of the remote location 1312 as desired (e.g., to thenetwork management system 1320 for handling).

In some embodiments, a number of secure gateway appliances 1322 areaccessible external to the remote location 1312. For example, in someembodiments, a separate secure gateway appliance 1322 could be madeavailable for every defined community of interest, such thatcommunications for a particular group of users are routed from a commongateway. In other embodiments, secure gateway devices dynamicallyallocate connection bandwidth to client computing devices 1304 based oncurrent bandwidth use, and connect to client computing devices 1304associated with users in a number of communities of interest. Otherarrangements of gateway devices are possible as well.

Additionally, at the remote location 1312, an authorization server 1324can be included which includes one or more provisioning and managementtools for managing memberships in communities of interest, as well asresources accessible by individuals associated with those communities ofinterest. The authorization server 1324 can, in certain embodiments, beconfigured to authenticate a user of a client computing device 1304 andassociated secure boot device 1306. The authorization server 1324 can beconfigured to, for example, receive username and password,cryptographically-signed certificate, or PIN or other information from auser of a client computing device 1304 seeking to connect to the remotelocation 1312 via a secure connection, and can transmit one or moreencryption keys to the client computing device 1304, such as anencrypted session key or other information from a cryptographic dataset, as discussed above in connection with FIG. 7.

It is noted that data connections between the secure gateway appliance1322 and a local server, such as the authorization server 1324, istypically trusted because of its co-location within a data center or theuse of a secure connection that is otherwise trusted. The secure gatewayappliance 1322 typically involves the use of encryption keys that areassociated with the identity of particular users. These keys may consistof public key encryption keys that would use a set of keys at the clientcomputing device 1304, and a corresponding set of keys at the securegateway appliance 1322. The set of keys used by the client computingdevice 1304 may be stored on the secure boot device 1306 and are notaccessible by the user. As part of the authentication process, theauthorization server 1324 may be used to perform any desiredauthentication and then identify the needed encryption keys that areneeded by the secure gateway appliance 1322 for use in performing thesecure communications.

In use, typical client operations contacting the remote location 1312can be performed using clear text communication. However, when a userwishes to perform one or more sensitive transactions involvingconfidential data, that user can reboot his/her client computing device1304 at the client location 1302 using a secure boot device 1306 asdiscussed above. Software modules from the secure boot device 1306 areloaded at the client computing device 1304, and optionally a user isprompted to enter his/her username, certificate, or other credentials.Upon authentication of that user, the client computing device 1304 willform a secure connection with a secure gateway appliance 1322 that iseither defined in memory of the secure boot device 1306 or received viathe authorization server 1324. The secure boot device 1306 will dictatecommunication with only the remote location 1312, and will requirecommunication to occur via the secure gateway appliances 1322.Accordingly, implementation of the distributed processing system 1300allows an entity to protect sensitive data being passed over public,IP-based networks.

It is noted that, to devices communicating via the internet 1318 usingclear text communications, the various devices communicating only viasecure communication protocols of the present disclosure (e.g., a clientcomputing device 1304 when securely booted using a secure boot device1306, a gateway appliance 1322, or the authorization server 1324 in theembodiment shown) appear non-responsive to other devices connected tothe internet 1318. For example, the authorization server 1324 may notrespond to communications in clear text, and one or more gateway devicesmay simply forward data received in clear text to the network managementsystem 1320. This includes both clear text devices, as well as otherclients and/or gateway devices operating using only a different set ofcommunity-of-interest keys. This prevents unauthorized access to thedata as transmitted, or “data in motion”, within the distributedprocessing system 1300. Additionally, it prevents network browsing andmalware injections by unauthorized systems via the internet 1318.

Referring now to FIG. 14, a second example of a distributed processingsystem 1400 useable in connection with a secure boot device to create asecure connection to a server is shown. In this embodiment, thedistributed processing system 1400 represents an arrangement in whichthe secure connection into an intranet of a remote system is provided asa managed service, i.e., by an entity other than the administrator ofthe intranet within which the secured, community-of-interest protectedresources reside. In this embodiment, the authorization server 1324exists connected to the internet 1318, separate from the remote location1312. In this second embodiment, a trusted connection from a securegateway appliance 1322 and the authorization server 1324 may be needed.In both of these cases, the secure gateway appliance 1322 is physicallyconnected via internet 1318 to the server providing the web application1316. Additionally, one or more external secure computing resources 1402can be included in the distributed processing system 1400 and use ofthose systems could be authenticated by the authorization server 1324 inthis embodiment, because it is not specifically only affiliated with theremote location 1312, but instead can transmit secure messages andprovide authentication via the internet 1318.

Referring now to FIG. 15, a third example of a distributed processingsystem 1500 useable in connection with a secure boot device to create asecure connection to a server is shown. In this distributed processingsystem, the secure gateway appliance 1322 is physically located in alocal intranet of a managed service provider 1502. A managed serviceprovider 1502 can be, for example, an entity configured to manageresources needed to administer communities-of-interest, encryption keys,access control lists, and other information typically managed by anadministrator of a local intranet. In the embodiment shown, thedistributed processing system 1500 includes a client computing device1304 and associated secure boot device 1306 as discussed above; thedistributed processing system also includes a remote location 1312, inthis embodiment being a customer of the managed service provider 1502.In the embodiment shown, the remote location 1312 includes an analogousentity intranet 1314, such as a data center network or other set ofresources, which is accessible via a web application 1316. The remotelocation 1312 also includes a network management system 1320, forexample for load balancing and routing of data within the intranet.

As compared to the two prior embodiments, in this embodiment the managedservice provider 1502 is illustrated as including a separate serviceenclave 1504 and a customer enclave 1506. As referenced in the presentdisclosure, an “enclave” generally refers to a particular area ornetwork of one or more computing systems defined by function.

Generally, the service enclave 1504 includes one or more computingresources configured to be managed by the managed service provider 1502,including management of community-of-interest keys, memberships incommunities of interest, authentication of users and granting of accessto resources in a secured location. In the embodiment shown, the serviceenclave 1504 includes a service appliance 1508, an administrationappliance 1510, an authorization server 1512, and a DHCP server 1514.

The service appliance 1508 is generally an appliance having a knownaddress, such that instructions stored in a secure boot device (e.g.,boot device 1306) include an address for that appliance, to allowauthentication of a user of the device. The service appliance 1508receives initial connection requests from one or more client computingdevices 1304, and establishes an encrypted connection to the clientcomputing device 1304 to provide the client with its one or morecommunity of interest keys, and other secure,community-of-interest-specific information. In certain embodiments, theservice appliance 1508 is accessible using either an administrationcommunity-of-interest key or a service key. The service key can be, forexample, a key provided to users, e.g., stored in a read-only portion ofthe secure boot device, such that the boot device itself is authorizedto and configured to connect to the service appliance 1508 to obtain oneor more community-of-interest keys therefrom.

The administration appliance 1510 provides access to the service enclave1504 for administrative tasks related to the service enclave 1504 andcustomer enclave 1506. Example tasks performed via access to theadministrative appliance include, for example configuring addresses ofgateway appliances, configuring membership lists in one or morecommunities of interest and keys associated with those communities ofinterest, logging events, creating and managing virtual private networkswithin the customer enclave 1506, and other tasks. In some embodiments,a user requires an administration community-of-interest key to accessthe administration appliance 1510, to prevent unauthorized access bycustomers or other unauthorized individuals.

The authorization server 1512 manages keys associated with each of theone or more communities of interest associated with the customer enclave1506. The authorization server 1512 receives login information from auser of a client computing device 1304 and associated secure boot device1306, and returns the COI keys and identity of the secure gatewayappliance to which that user is authorized to connect (discussed below).The DHCP server 1514 manages addressing of systems within the serviceenclave 1504, providing IP addresses for resources accessible via theservice appliance 1508.

The customer enclave 1506 includes a secure gateway appliance 1322, aswell as a network addressing table (NAT) 1518. The secure gatewayappliance 1322 provides an endpoint to which all secure communicationsfrom the client 1304 are directed, while the NAT 1518 receives cleartext communications from the client computing device 1304 or remotelocation 1312. Preferably, the resources accessible via the securegateway appliance 1322 and the NAT 1518 are not coextensive, i.e., noclear text communications via the NAT reach the network resourcesspecifically associated with the community-of-interest enabled at theclient computing device 1304 and the secure gateway appliance 1322. Inthe embodiment shown, a DNS server 1520 and DHCP server 1522 areincluded at the customer enclave 1506. The DNS server 1520 allowsdefinition of one or more virtual private networks among computingresources in the customer enclave 1506, thereby allowing for segregationof computing resources on a community of interest basis within thecustomer enclave. The DHCP server 1522 allows each endpoint connectingto the customer enclave 1506 to acquire a secured private networkaddress to be used in the customer's secured portion of the customerintranet within the customer enclave 1506. Static routes are configuredvia the DHCP server 1522 to allow TCP/IP packets from a client to beproperly routed to the customer intranet.

It is noted that in the example of FIG. 15, the secure gateway appliance1322 can be used, not only by more than one community of interest withina particular entity as discussed above with respect to FIGS. 13-14, butcan also be addressed by multiple different, unaffiliated customers ofthe managed service provider 1502. Accordingly, additional remote sites1312 and client computing devices 1304 could be incorporated as well.

For example, a first client computing device 1304 may be affiliated witha first entity, and a second client may be affiliated with a secondentity. To initiate secure communication with that user's specificresources within the customer enclave, both clients would first accessthe service enclave 1504, via the service appliance 1508, using the sameservice key. Upon validation, each of the first and second client wouldretrieve its own respective community-of-interest keys associated withthe users of those clients, e.g., based on his/her roles relative to theentity with which those users are affiliated. The service enclave 1504can be configured to provide relevant community-of-interest keys relatedto users of both the first and second clients to the secure gatewayappliance 1322, or to different gateway appliances associated with thesame customer enclave 1506. When each respective user is validated andaccesses his/her community of interest keys (e.g., via the methods andsystems of FIG. 12, above, or FIG. 17, below, that user can initiatecommunication with a secure gateway appliance 1322 using thecommunity-of-interest key to access user- and entity-specific resources(e.g., virtual private LANs, SANs, or other resources) managed withinthe customer enclave 1506.

Once a secure connection is established, data is routed to a securegateway appliance 1322 for communications with the server 1524 at thecustomers intranet (e.g., intranet 1314) running the web serviceapplication 1316, the banking application for example. In this thirdembodiment, the server 1524 may be located in a separate location on theInternet. A separate secure connection may be used to connect the securegateway appliance 1322 and the server 1524.

FIG. 16 illustrates a flowchart 1600 of creating a secure connectionaccording to an embodiment of the present invention. The flowchart 1600outlines example steps taken by a user, a customer facility, and one ormore configuration devices or entities (e.g., an entity responsible forconfiguring authentication of the user within a virtual networkaffiliated with the customer facility). A configuration data collectionoperation (step 1602) involves

A BIOS modification operation (step 1604) involves modifying a BIOSconfiguration setting within a BIOS of a computing system, such that thecomputing system can be used as a terminal to connect to a remoteserver, for example to conduct transactions with a bank or otherfinancial institution. In general, the BIOS modification operationinvolves assigning a boot order to devices associated with the computingsystem operated by the user (e.g., client computing device 1304). Insome embodiments, the BIOS modification operation enables the clientcomputing system to boot from a USB device, such as the secure bootdevice described in some embodiments above.

A terminal launch operation (step 1606) corresponds to a user insertinga USB-stick boot device into a USB port of a computing system, andrebooting the computing system via that particular secure boot device.The terminal launch operation further includes, upon the computingsystem booting from the secure boot device, entering one or more typesof user credentials when prompted by the computing system, for exampleto validate the user's identity (e.g., using a username and password,cryptographically-signed certificate or PIN number security system).

A location selection operation (step 1608) allows a user to select aparticular location to which to connect. For example, the locationselection operation may in certain embodiments allow a user to select aparticular branch of an institution, or a particular region, or aspecific division of that institution. In any event, selection of alocation via the location selection operation allows the method 1600 todetermine the particular secure gateway device to which the clientcomputing system will connect. If the user elects to add a new location,a new location operation (step 1610) receives network and configurationdata for that new location. The new location can, for example, be aparticular branch or other division of the institution to which securetransactions are desired for that user, in the context of the presentdisclosure, a new location will typically be a location having aseparate secure gateway device; however, other arrangements are possibleas well for defining a new location.

A terminal initiation operation (step 1612) presents a welcome screen toa user, and transmits to the user via a SSL or other tunnel-basedconnection the one or more community of interest keys associated withthat user. Alternatively, in some embodiments, the community-of-interestkeys are stored on the secure boot device, and the terminal initiationoperation can send a decryption key to the now-secure-booted clientcomputing system to decrypt and access those community-of-interest keys.

A secure tunnel operation (step 1614) sets up a secure tunnel betweenthe client computing system and the designated location (e.g., anaddress of a secure gateway device) using the one or more community ofinterest keys and other encryption information associated with thatuser. If necessary, the one or more community of interest keysassociated with the user are transmitted from an authorization server tothe identified secure gateway device, allowing that device tocommunicate with the client computing device, thereby enabling thesecure connection between those devices via the internet.

A login operation (step 1616) receives login information from a user,for example a username and password, a cryptographically-signedcertificate, or PIN-based authorization. The user is validated, and canconduct one or more transactions at a transactions operation (step1618), which corresponds to execution of one or more transactions at acustomer facility.

While the above embodiments of the present invention describe theinteraction of a client computing system and a server computing systemover a secure communications connection, it is recognized that otherarrangements for secure connection and communication between a clientdevice and server system or dedicated customer resource is possible. Aslong as a secure boot device, such as a USB memory stick, as describedherein, is used to boot the client computer and to create the connectionwith the server, the present invention to would be useable in performingsecure transactions. Additionally, any of a variety of methods forsecuring an otherwise unsecure terminal could be used as well. It is tobe understood that other embodiments may be utilized and operationalchanges may be made without departing from the scope of the presentinvention.

Referring generally to FIGS. 10-16, it is recognized that using thesecure communications infrastructures discussed herein, a number ofadvantages are obtained over existing secure connections. For example,using the secure boot devices and resulting secure terminal connectionto resources over a public network (e.g., the Internet), a user is stillable to maintain a trusted, virus-free computing system at a clientsite, despite potential corruption issues both relating to datatravelling over the open network and data stored at the client device(e.g., on a hard drive of the client device). This reduces the risk ofvarious types of phishing, eavesdropping, and screen- or keystrokerecording, because the institution to which a client user connectsreliably knows what software is operating at that client device.

IV. Coexistence of Secure Tunnels with Internet-Based Infrastructure

Referring now to FIGS. 17-21, example methods and systems are disclosedrelating to a further possible embodiment of the present disclosure inwhich a secure tunnel connection, such as those described above usingcommunity-of-interest based encryption and segregation of resources, canbe used in conjunction with clear text communication to apublicly-available resource, such as an internet site. FIG. 17illustrates a basic example network in which such an arrangement mayoccur, while FIGS. 18-19 illustrate particular example networks similarto the managed service network described above in FIG. 15, in which sucha hybrid secured/unsecured arrangement is managed. FIGS. 20-21illustrate example methods for managing concurrent secure and unsecuredconnections at a client device.

Referring now to FIG. 17, an example network 1700 is shown in whichsecure tunnels can coexist with clear text communication, according to apossible embodiment of the present disclosure. In the network 1700, aclient device 1702 connects to a secure appliance 1704 via an opennetwork, such as the internet 1706. One or more public sites 1708 arealso available to be accessed from the client device 1702.

In this embodiment, client device 1702 corresponds generally to anycomputing system capable of secure communication usingcommunity-of-interest based security and the cryptographic securityarchitecture generally described above in connection with Section I. Theclient device 1702 can be, for example a computing system as discussedin connection with FIGS. 4-6. The secure appliance 1704 can alsogenerally be any secured endpoint or gateway device, such as thosedescribed above.

In the embodiment shown, the client device 1702 includes one or morecommunity-of-interest keys 1710 and an associated one or more filters1712. In one embodiment, each community-of-interest key has anassociated filter; in other embodiments, different numbers of keys andfilters can be used.

Generally, the community-of-interest keys 1710 stored on the clientdevice 1702 are used to cryptographically split messages passed to aparticular endpoint known to be capable of reconstituting those messagesfor use at an opposite end of an unsecured network, so as to providesecurity between the two endpoints. In certain embodiments disclosedherein, an additional clear text community-of-interest key can be usedwhich, when associated with a particular message, allows forcommunication of clear text messages concurrently with use of securecommunication (including use of the secure software stack 608 of FIG.6).

Optionally, associated with each of the community-of-interest keys 1710,a filter 1712 can be defined, for example by an administrator of asecure network, using a provisioning utility of an administrationappliance. The filter 1712 defines one or more permissions associatedwith each community-of-interest key 1710. Each filter can take a varietyof forms. In one example embodiment, a plurality of filters can bedefined in an XML file associated with each community of interest, andwhich are delivered to a user alongside any relatedcommunity-of-interest key(s). For example, a filter can define a key byits key name, and then define an allowed access list of IP addressesrelating to endpoints that the client device 1702 is permitted tocommunicate with using the identified key, or optionally an “exclusions”access list of IP addresses relating to endpoints that the client device1702 is not permitted to communicate with. An example of a portion of afilter 1712 is illustrated below, in which two community-of-interestkeys are defined:

<tuples> <key id=ClearText1> <type>5</type> <keyName>keyname</keyName><denyAccessList> <IPAddress name=”*”> <exceptFor count=”1”> <IPAddressname=”121.15.20.31” /> </ exceptFor> </IPAddress> </denyAccessList></key> <key id=Stealth1> <type>0</type> <keyName>keyname</keyName><hostIP> 139.72.10.10</hostIP> </key> </tuples>

In this example, a clear text filter, defined as “ClearText1” allows anassociated endpoint to communicate with any endpoint except for one ataddress 121.15.20.31, which is included in an exclusions list (deniedaccess). Further, a second filter, defined as “Stealth1”, has nospecific exclusions or limitations on where it can or cannot transmitmessages, but is specifically instructed that it has a “home” gatewaylocated at 139.72.10.10. If both of these filters are associated withthe same user, that user could communicate with a number of networkaddresses via clear text, while also communicating with various networklocations via the secured connection and community-of-interest keyassociated with the “Stealth1” filter, including the endpoint or gatewayat 139.72.10.10. Other example filters could be defined as well, forexample to exclude clear text communication from occurring to the sameendpoint to which secured communication is directed from a given clientdevice.

In some embodiments, client device 1702 can include an application 1714that runs as a background process and which manages selection of one orboth of clear text and cryptographically secure communication settings.In such embodiments, client device 1702 can be configured to selectivelyallow or disallow use of one or more clear text or secure filters bydisabling that type of communication at the application level. Inadditional embodiments, the client device 1702 is by default configuredto include a clear text filter, and does not need to retrieve thatfilter from a remote system such as an authorization server. Once theauthorization server in fact authorizes the client device 1702 forcryptographically secure communications and community-of-interest keysare provided to that client device 1702, the clear text filter may bemodified, for example to prevent clear text communication to a knownsecure appliance 1704 configured to communicate with the client device1702 using cryptographic security. Other embodiments are possible aswell in which the clear text filter is selectively provided to eachclient device 1702 by an authorization server as needed/desired.

Additionally, in some embodiments, secure appliance 1704 or clientdevice 1702 can generate a tunnel status report 1716 relating toactivity at the secure appliance 1704, either specifically relating toclient device 1702 or generally relating to any client devicetransmitting packets to the secure appliance. Example informationincluded in the tunnel status report 1716 can include, for example, acurrent connection status and keys used for connection to the secureappliance by one or more client devices. Other information can beincluded in the tunnel status report as well.

As can be seen from this key/filter arrangement, the network 1700provides added functionality to existing secured networks (e.g., VPN)which route all traffic via a secure tunnel when such a tunnel has beenformed between endpoints. Furthermore, as compared to the securetransactional systems described above in connection with FIGS. 10-16, inthis arrangement, a user of a client device is not precluded fromaccessing unsecured resources; accordingly, a user of a secure bootdevice or other system that typically prevents communication other thanto a particular gateway or server of an institution can use the methodsand systems discussed herein to also allow access to all or selectedpublicly available sites accessible via clear text browsing.

Referring now to FIG. 18, a distributed system 1800 is illustrated inwhich secure tunnels and clear text communication can exist, accordingto a possible embodiment of the present disclosure. In this embodiment,the distributed system 1800 generally illustrates use of concurrentclear text and secured communications from the same endpoint whileconcurrently using a secure managed service network. This arrangementmay be implemented, for example, by one or more companies or otherentities wishing to communicate from a trusted intranet to a remotelymanaged network application via an open network. In cases such as thatdepicted in FIG. 18, where that remotely managed network applicationmanages sensitive data, a secure communication arrangement is desiredbetween the local intranet and that remotely managed application, butconcurrent normal, clear text access to a public network site (e.g., anaddress accessible via clear text on the internet) is desired as well.

In the embodiment shown, the distributed system 1800 includes a set ofclient devices 1802, each located in customer local area networks 1804a-b. Both customer local area networks 1804 are connected to a serviceenclave 1806 and a customer enclave 1808 via a public network, shown asthe internet 1810. The internet 1810 additionally connects the localarea networks 1804 a-b to a variety of publicly-available internetsites, in the example shown as public internet site 1812. Additionally,one or more client computing systems 1802 can be directly connected tothe internet 1810 without being a part of a customer local area network1804, for example a home user or other remote access user wishing toaccess applications or resources managed at the customer enclave 1808.

The service enclave 1806 includes a plurality of computing devices,depending upon the particular requirements of the managed entities. Inthe embodiment shown, the service enclave includes a service appliance1814, and a plurality of computing devices 1816 a-d. In variousembodiments, one or more of the computing devices 1816 a-d can includean administration gateway including a provisioning tool, by which anadministrative user can define and provision one or more other gateways,endpoints, and network resources. Others of the computing devices 1816a-d can be an authorization server configured to provide authenticationof users connecting to the service enclave 1806 via a service gateway.Still other computing devices 116 a-d can provide DHCP or other networkrouting services.

The customer enclave 1808 includes a customer appliance 1818 as well asa plurality of computing devices 1820 a-b. In various embodiments, thecustomer enclave can be managed by the one or more computing devices1816 a-d of the service enclave to form one or more virtual privatenetworks, with each such network associated with a particular communityof interest. Each community of interest can be specific to one of thecustomers (e.g., a separate community of interest for each customerlocal area network 1804 a-b, respectively), or based on an identity of auser within those networks. Accordingly, the generalized networktopology of the distributed system 1800 is similar to that illustratedabove in conjunction with FIG. 15, but is adapted for use by either anuntrusted client device and associated secure boot device, or for secureaccess from a trusted client, such as a client within a trusted clientintranet (e.g., customer local area network 1804).

In general, the key and filter arrangements of the present disclosureallow concurrent access to both secured systems, such as those at theservice enclave 1806 and customer enclave 1808, as well as to publicinternet site 1812, as desired. To allow a particular user access toboth secured and unsecured resources, that user must simply be includedwithin a secure communities of interest and a clear text community ofinterest, such that the client computing system associated with thatuser will receive a community-of-interest key, as well as one or morefilters defining allowed secure and clear text communication. Dependingupon the definitions included in the filter associated with thecommunity-of-interest key, the user may be allowed partial or full cleartext communication capabilities, while concurrently communicatingsecurely with one or both of the service enclave and customer enclave.

FIG. 19 illustrates a more particular example of a distributed hybridsystem 1900. In this example, a network topology is illustrated thatallows use of any of clear text, virtual private network, or secureconnections, using the distributed systems of FIGS. 17-18, according toa possible embodiment of the present disclosure. In this system, a usercan connect to a private cloud, such as a customer enclave 1902, via apublic network such as the internet 1904, using one or both of a VPNconnection and a cryptographic, community-of-interest-based connectionaccording to the principles of the present disclosure. In the embodimentshown, a client device 1906 is configured at a customer intranet 1907with both a “stealth” based cryptographic splitting virtual adapter anda virtual private network virtual adapter. This can correspond, forexample to the network interface infrastructure illustrated in FIG. 6,described above, in which first and second secure communication stacks,e.g. software stack 608, 609 are implemented.

The customer enclave 1902 includes, in the embodiment shown, a DHCPserver 1908, a domain server 1910, a stealth server 1912, and anapplication server, shown as Exchange server 1914. Other networkresources could be included in the virtual private network as well. Fromthe internet 1904, the virtual private network shown as the customerenclave 1902 can be accessed via either VPN server 1916, or a secureappliance (e.g., from secure appliances 1918 a-b). Additionally, one ormore public internet sites 1920 are available to a client device 1906via the internet 1904.

In this example configuration, the client device 1906 is configured withboth a Stealth virtual adapter (illustrated as being assigned IP address172.30.0.100) and a VPN virtual adapter (illustrated as being assignedIP address 172.31.0.110). The client device 1906 is further configuredwith a clear text filter, analogously to the example of FIG. 17, toallow access to the public internet sites 1920 via clear text, and tothe VPN server 1916. Additionally, the physical adapter with the NATassigned IP address (10.0.0.11) is used for local communications toother endpoints in the NAT subnet, e.g., at the same location as theclient device 1906.

In certain embodiments, the customer enclave 1902 includes a DHCP server1908 to allow the client device 1906 to acquire a Stealth VPN address tobe used in the Stealth-enabled portion of the customer's intranet 1907.Static routes are configured via the DHCP server 1908 to allow TCP/IPpackets on the endpoint to be properly routed to the customer intranet1907. The destination IP address/subnet in the customer intranet isconfigured with a static route so Windows TCP/IP selects the correctvirtual adapter. For example, if the client device 1906 is using thesecure appliances 1918 as a destination, then the stealth virtualadapter must be selected by Windows TCP/IP stack in that client device.If the destination is using the VPN path (i.e., via VPN server 1916),then the VPN virtual adapter must be selected by Windows TCP/IP.

Referring now to FIGS. 20-21, methods for authenticating a system foruse of coexisting stealth-enabled and clear text tunnels are described,as well as for configuring a distributed system including such tunnelsusing a provisioning utility. FIG. 20 illustrates a flowchart of amethod 2000 for authenticating a client device, such as an endpoint, foruse of coexisting secure and clear text tunnels, according to a possibleembodiment of the present disclosure. The method 2000 generallycorresponds to a client device requesting authorization from anauthorization server, such as may be located within a service enclave ofa managed environment, to communicate with one or more other endpointsor gateway devices using secure, stealth-based communication and cleartext communication to other locations in an open network.

The method 2000 is initiated, a request is transmitted for authorizationof a user from a client device to a service enclave, for example to theauthorization server (step 2002). The request can include, for example auser identifier and password or other authentication information, suchas a PIN based authentication.

At an authorization server, the identification of the user of the clientdevice is checked against a list of communities of interest that aredefined using a provisioning utility at the service enclave. Once theclient device associated with the user is authorized, it receives one ormore community-of-interest keys and filters defining connection rightsfrom a remote system (step 2004), such as an authorization server via aservice appliance, as discussed above. The community-of-interest keysand filters define the available endpoints to which the client devicecan communicate and receive communication, both in stealth-enabled(cryptographic) and clear text.

Once the client device has received the community-of-interest keys andfilters, it can communicate using the community-of-interest keys aslimited by the associated filters. In step 2006, the client device cantransmit one or more messages to one or both of clear text orcryptographically-enabled endpoints using a clear text or secure filteralongside a specified community-of-interest key, if that message (cleartext or cryptographic) is allowed based on the defined access lists(both inclusion and exclusion permissions) in the associated filter. Instep 2008, the client device can also receive one or more messages fromone or both of clear text or cryptographically-enabled endpoints. It isnoted that, even if the remote endpoint transmits a message in cleartext or using a community of interest key available on the endpoint, thecommunications software stack at the client device will discard themessage if received from an unauthorized remote endpoint, as defined inthe filters received at the client device.

FIG. 21 illustrates a flowchart of a method 2100 for configuring adistributed system including coexisting secure and clear text tunnelsusing a provisioning utility, according to a possible embodiment of thepresent disclosure. The method 2100 can be used, for example toassociate users with communities of interest and defining filters to beassociated with those communities of interest, thereby controllingaccess to endpoints (clear text and cryptographically secured) for thatparticular user. The method 2100 can be performed, for example, using anadministration appliance, such as those discussed above in connectionwith FIGS. 15 and 18.

The method 2100 is initiated by opening a provisioning utility, such ascan be made available via an administration appliance of a serviceportal, and defining one or more communities of interest and filtersassociated with those communities of interest using the provisioningutility (step 2102). This can include, for example, using a provisioningtool of an administrative gateway to define communities of interest andfilters, as discussed above in connection with FIGS. 17-18.Alternatively, the one or more communities of interest can be definedbased on a user's membership in another user group, such as a definedgroup within Active Directory. In such an arrangement, those predefinedgroups could be associated with particular keys, filters, and accesspermissions using the provisioning utility.

After the distributed system is provisioned, a service enclave canreceive an authorization request from a client device or endpoint (step2104). The service enclave typically establishes a secure connectionwith the client device using a service key to maintain encryption. Theservice key can, for example be stored in an obscured location at aclient device. In one example embodiment, the service key can be storedin a registry entry at a client device. In another example embodiment,the service key could be stored within a read-only or read-write memoryof a secure boot device, such as a device as described above inconnection with FIGS. 10-16. Other storage arrangements for the servicekey could be used as well.

A set of communities-of-interest are determined to be associated withthe user of the client device (step 2106), for example at theauthorization server. The authorization server returns thecommunity-of-interest keys and filters, alongside any other informationin a cryptographic data set, to the client device (step 2108), for usein establishing a secure connection with a customer enclave.

Although in FIGS. 20-21, a particular order of operations isillustrated, it is understood that other arrangements of these methodsare possible. Additionally, more or fewer steps could be used toaccomplish the provisioning and access methods described herein.

Overall, referring to FIGS. 17-21, it can be seen that using thecommunity-of-interest keys and filters, alongside the communicationsinfrastructure provided at a computing system as discussed above inconnection with FIGS. 4-6, a user can be enabled to communicate viaclear text with selected public sites via the internet whileconcurrently communicating via cryptographic security features withother secure endpoints. This allows even trusted terminals, such asthose using secure boot devices described above in connection with FIGS.10-16, to perform both dedicated secure operations and to accessexternal websites to the extent allowed by an administrator of adistributed system. Additionally, concurrent clear text andcryptographic communication allows an administrator to implement ahybrid access arrangement in which any of clear text, virtual privatenetwork, or stealth-enabled, cryptographic communications can be used.

V. Updating of and Key Management in Secure Endpoints

Referring now to FIGS. 22-25, example systems and methods for managingkey distribution throughout a distributed system are described, andmethods for updating security and system software at remote terminalsare also described in the context of such a distributed system. Thedistributed system used can be, for example, a network providing amanaged service to one or more customers, such as would include theexample service and customer enclaves discussed in the above examplesillustrating other features of such a system.

FIGS. 22-24 illustrate three example networks that can be deployed tomanage encryption keys and provide software updates to secure clientsoftware. FIG. 22 illustrates an example distributed system 2200 inwhich a secure terminal can be updated during secure connection to acustomer virtual network, according to a first possible embodiment ofthe present disclosure. The distributed system 2200 includes a pair ofclient computer systems 2202, illustrated as being generalized computingdevices having associated secure boot devices 2204. The client computersystems 2202 can be located at a common location, or can be at differentlocations. The client computer systems 2202 can also be associated withthe same or different customers, and the users of the client computersystems 2202 can be part of the same or different communities ofinterest.

The secure boot devices 2204 can be, for example, USB-based memorydevices storing a plurality of software modules used to create a secureterminal at the client computer systems 2202. As mentioned brieflyabove, each of the secure boot devices 2204 can optionally includestored thereon a secure service key and address identifier of a serviceappliance, such as service appliance 2206 useable to securely connect toa service enclave 2208. In such embodiments, the service key can, forexample, be stored within a shell operating system's registry settings.Connection to the service enclave 2208, and subsequently to a customerenclave 2210 (discussed in further detail below) occurs via internet2212.

An authorization server 2214 within the service enclave 2210 transmits acryptographic data set to the client computer system 2202, which can actto validate the user and provide, for example, one or morecommunity-of-interest keys, one or more filters, a location of a securegateway to which the customer can connect to access the customer enclave2210, and other information. In certain embodiments, the authorizationserver 2214 encrypts the above information for transmission to theclient computer system 2202 in a manner specific to that client computersystem (e.g., using a key known by the client computer system due todata stored on a secure boot device 2204).

The service enclave 2208 includes a number of additional features nottypically used directly by a user of a client computer system 2202, butrather for management of communities of interest and encryption keysassociated therewith. In the embodiment shown, the service enclave 2208includes a router connecting service appliance 2206 to a variety ofother servers and networking equipment, including an administrationappliance 2216, and a router 2218 configured to connect to theauthorization server 2214 and other networking components used tomaintain and monitor the service enclave 2208, including a DNS server2220, a DHCP server 2222, a system logging server 2224, and a stealthadministration server 2226. The administration appliance 2216 providesan interface to a remote administrator of the distributed system, forexample an owner of the managed service (i.e. the service enclave 2208and customer enclave 2210). The interface of the administrationappliance 2216 allows an administrative user to configure one or morecommunities of interest and filters as discussed above, as well asconfigure virtual and physical networks in the service and customerenclaves, and schedule and configure updates needed for any trustedsoftware modules executing on client computer systems 2202 and stored onsecure boot devices 2204. Additional functionality could be incorporatedinto the administration appliance 2216 as well

The stealth administration server 2226 can, in some embodiments,maintain a listing of communities of interest, as well as a listing ofauthentication information and users associated with that authenticationinformation. The authentication information can be username and passwordinformation, a cryptographically-signed certificate, or can be PIN-basedor other code information associated with a particular secure bootdevice 2204. This information can be accessed by the authorizationserver 2214 in response to receipt of requests for access to a customerenclave received from client computer systems 2202. It is noted thateach of these components could be a physical server system, or could beimplemented as a virtual system within the service enclave 2208.

In certain embodiments, the authorization server 2214 or some othercomponent within the service enclave 2208 can also transmit to theclient computer system 2202 an update script alongside the one or morefilters, community-of-interest keys, and other information used forestablishing a secure connection to a customer enclave 2210. In someembodiments, the authorization server 2214 transmits the update scriptwhen an update becomes available to alter the one or more securesoftware modules stored on a secure boot device 2204 (e.g., a version ofthe software modules identified by the client device as present on thesecure boot device is out of date). As discussed above, in someembodiments, the authorization server 2214 transmits encryptedcommunity-of-interest keys and other information to the client computersystem 2202 such that the encryption is performed in a manner specificto that client device.

When a customer wishes to initiate communication with a customer enclave2210, the customer will establish a secure tunnel with an identifiedsecure gateway 2228 using the one or more secure community-of-interestkeys received as part of the cryptographic data set from theauthorization server 2214. Once the secure connection is establishedwith the secure gateway 2228, the customer can access one or moreadditional resources within the customer enclave 2210, such as a webapplication 2230 or other application configured to allow securetransactions, or a hosted application or data storage, as discussedabove. The customer enclave 2210 optionally includes a router 2231 orother internal logical routing equipment for directing customercommunications to a particular application (e.g., web application 2230)or area associated with that customer, based on identifying usersassociated with that customer by the communities of interest to whichthey belong. The customer enclave 2210 also, in the embodiment shown,includes a DNS server 2232 and a DHCP server 2234, useable to route dataamong various virtual private networks and/or systems present within thecustomer enclave.

In the embodiment shown in FIG. 22, an update server 2236 is locatedwithin the customer enclave 2210, and is configured to, based on thecontents of an update script delivered to the client computer system2202 by the authorization server 2214. To update the software on theclient computer system 2202, the update server 2236 will transmit to theclient computer system 2202 a set of one or more software modulesuseable to implement the secure connection between the client device andone or both of the service enclave 2208 and the customer enclave. Theset of one or more software modules can be a complete replacement of thesoftware modules present in rewritable memory of the secure boot device2204, or can alternatively include only a portion of the informationincluded on the secure boot device.

As discussed further in connection with FIG. 25, below, the updateserver 2236 can deliver an update as defined on the update scriptconcurrently with a client computer system 2202 performing one or moretransactions in the customer enclave 2210, such that the update occursin the background (i.e., is opaque to the user of the client computersystem 2202). In certain embodiments, the size of an update can besubstantial (e.g., greater than 1 gigabyte); as such, the updatetransfer process for transmitting the update to the client computersystem 2202 can be interruptible, and can be restored during a nextsubsequent connection between the client computer system 2202 and thecustomer enclave 2210. For example, a user can direct or schedule anupdate using update client software stored on a secure boot device, suchas discussed above in connection with FIG. 11B. Additionally, the updateclient software can, in certain embodiments, allow a user to view astate of the update (e.g., amount of update software that has beendownloaded or is yet to be downloaded).

In an alternative embodiment to that shown in FIG. 22, the update server2236 can be located within the service enclave 2208, rather than thecustomer enclave 2210. In such embodiments, when the client computersystem 2202 is securely connected to the customer enclave 2210, theclient computer system 2202 can concurrently maintain a connection tothe service enclave via the service key. In such embodiments, the clientcomputer system 2202 can also continue to communicate with the serviceenclave, for example to receive software updates to the secure bootdevice 2204 from the update server 2236.

In still a further alternative embodiment to that shown in FIG. 22, theupdate server 2236 can be located within a separate update enclave. Sucha separate update enclave can include one or more computing systems,such as those shown to be incorporated in the service enclave 2208, butcould be used to separate the authentication and updatingresponsibilities across multiple enclaves. This could be used, forexample, to reduce bandwidth stress on the service enclave and customerenclave, depending upon the number of authorization requests and updatesrequired.

FIG. 23 illustrates a second example distributed system 2300 in which asecure terminal can be updated during secure connection to a customervirtual network. In the distributed system 2300, web application 2230resides within a customer network 2302. The customer network 2302 can belocated behind a firewall 2304, separating it from the internet 2212. Inthis arrangement, although the customer of the managed service canretain control over the web application 2230, communication with thecustomer enclave 2210 from the customer network 2302, as well as fromcustomers remote from or otherwise detached from the customer network(e.g., client computer system 2202 a) can connect to the customerenclave 2210 and service enclave 2208 for updates, data storage, andother features by way of a secure connection, for example using a secureboot device 2204.

FIG. 24 illustrates a third example distributed system 2400 in which asecure terminal can be updated during secure connection to a customervirtual network. In this arrangement, the distributed system 2400 can belocated entirely within a customer's enterprise network, such that onlythat customer will access the service enclave 2208 and customer enclave2210, with each of the communities of interest defined within the system2400 representing separate departments or sub-organizations within thecustomer's infrastructure. In this embodiment, the arrangement of theservice enclave 2208 and customer enclave 2210 can generally correspondto that shown in FIG. 22; however, in this embodiment, an additionalinterface between the authorization server 2214 and a customeradministration infrastructure 2402 may also be included in the serviceenclave. The customer administration infrastructure 2402 can, in certainembodiments, include a customer's internal user validation system, suchas a local area network authentication system, for example ActiveDirectory-based authentication (e.g., Kerberos), or other type ofauthentication system that can receive external authentication messages.

As with FIG. 22, above, in both of FIGS. 23-24, the update server 2236can be located either within the customer enclave 2210 as shown, oroptionally within the service enclave 2208 instead. Example reasons forplacing the update server 2236 within the service enclave 2208 includeseparation of bandwidth required for responding to requests from acustomer enclave 2210 from bandwidth required for performing an update,and maintaining more universal control over updates of securityfeatures, for example in the case of a managed service provider wishingto control update distribution from a service enclave while allowingcustomers to manage/control their own customer enclave resources. Otherreasons for placing the update server 2236 in the customer enclave 2210or the service enclave 2208 may exist as well.

FIG. 25 is a flowchart of a method 2500 for updating a secure virtualterminal connected to a distributed system, according to a possibleembodiment of the present disclosure. The method 2500 can be performed,for example, in any of the distributed systems described above,particularly those discussed in connection with FIGS. 22-24 in which anupdate server resides within a service enclave or customer enclave. Themethod 2500 begins with a user of a client device transmitting a requestfor validation at a service enclave, such as at an authorization server(step 2502). This can include, for example, transmitting a username andpassword, cryptographically-signed certificate, or PIN number forauthorization of a particular user, or an identity of a particularsecure boot device, or some combination thereof. Optionally, thevalidation step can also include transmitting an identifier of a versionof a set of software modules stored at a client device. The softwaremodules can include, for example, one or more secure software modulesstored on a secure boot device, as discussed above in connection withFIGS. 10-16. Alternatively, the software modules can include one or moredriver files used to perform cryptographic communications, such as thedriver files discussed above in connection with FIGS. 1-9. Otherpossibilities exist as well.

After the user is validated at the service enclave, the user can beauthorized to connect to a customer enclave (step 2504). Thisauthorization can take a number of forms. In some embodiments, theauthorization includes transmitting to the client device associated withthe authorized user or secure boot device a cryptographic data setincluding information required to create a secure connection to thecustomer enclave, such as one or more community-of-interest keys andassociated filters, an address of a particular gateway device throughwhich to access the customer enclave, and other cryptographicinformation. Authorization of the client can include, for example,encrypting and transmitting to the client device the one or morecommunity-of-interest keys and associated filters, as well as otherinformation used to connect to a particular gateway or customer enclave.Additionally, this authorization step can include transmitting to theclient device one or more update scripts defining an update process tooccur on the client device.

A secure connection can be established to the customer enclave (step2506) once the client device receives the necessary cryptographic data.This can include, for example, establishing a tunnel between the clientdevice and a gateway device identified by the authorization server inthe service enclave, using one or more community-of-interest keysprovided to the client device, as discussed above.

Once connected to the customer enclave, a client device can be used toperform transactions in the customer enclave (step 2508). Various typesof transactions could be performed; example types of transactions arediscussed above in connection with FIGS. 10-16. Concurrently with theuser connected to the customer enclave, an update server can deliver toa client device one or more updated software modules, based on theupdate script received at the client device (step 2510). In someembodiments, the software modules can be, for example trusted softwaremodules 1101-1104 of FIG. 11A, as included within a secure boot image.In other embodiments, the software modules can include one or morefilters, community-of-interest keys, service keys or service enclavelocations, driver software, or other information to be installed orstored at a client device for use in establishing a secure connectionbetween the client device and a remote system, or for ensuring that theclient device is not infected by malware of some type when suchcommunication is established.

Although illustrated as occurring concurrently with transactionsperformed using the customer enclave, it is recognized that transmissionof an update to a secure client device can occur either before or aftercommencement of transactions at the customer enclave. For example, insome embodiments, at least a portion of an update can occur prior tolaunch of an application for performing such transactions. Otherarrangements and orders of operations within the method 2500 arepossible as well.

It is recognized that in performing this update step, the update servercan, in various embodiments, transmit an encrypted, compressed versionof one or more software modules (or portions thereof) to a client devicefor use as a replacement to modules in a secure boot image. In someembodiments, one or more modules are transferred to a client deviceassociated with a secure boot device, and then transmitted to the secureboot device once completely received, thereby overwriting existingtrusted software modules. In other embodiments, the modules to beupdated are transferred and stored in a temporary storage area of thesecure boot device. In such embodiments, when completely transferred,the modules are then copied into a location reserved for the trustedsoftware modules on the secure boot device, thereby overwriting theprior versions of the trusted software modules. In this embodiment,different client devices could be used for different connection sessionswith the update server without requiring the updated software modules tobe entirely resent if not completed during a previous session.

Referring now to FIGS. 21-25 generally, it can be seen that, through useof a two-level key management scheme, communities-of-interest and keysrelated thereto can be managed and updated in a centralized manner,allowing changes in a service enclave to be propagated to users andcustomer enclaves as customers access the managed service. Additionally,through use of a dedicated update server, optionally included within aservice enclave, a customer enclave, or an entirely separate updateenclave, update processes can be offloaded from a service or applicationhosting system, allowing updates to be performed concurrently withtransaction processing (e.g., at the customer enclave). This reduces thebandwidth demands from the customer enclave and service enclave, each ofwhich may be concurrently hosting multiple users associated with anentity or community of interest, or multiple entities or communities ofinterest.

VI. Switching Between Multiple Languages of a Remote Desktop Client

Referring now to FIGS. 26-29, generally, disclosed are methods andsystems for switching between multiple languages of a remote desktopclient. As will be described herein, the remote desktop client,accessible through a secure boot device, is configured to be displayedin multiple languages that may be stored in the custom content area 1128of the secure boot device, such as secure boot device 1002 shown in FIG.11B.

FIG. 26 illustrates a flowchart of an example method 2600 for switchinglanguages of a remote desktop client operating on a secure boot device1002. In the example illustrated, the method 2600 is performed by thesecure boot device 1002. In this example, the method 2600 begins withstep 2602 in which the operating system is initiating from the secureboot device 1002. In some embodiments, this step 2602 of initiating anoperating system from the secure boot device 1002 begins by initiallysuspending the operating system used by the client computing device,such as client computer system 1006 and thereafter rebooting using anoperating system stored on the secure boot device 1002. As describedherein, the secure boot device enables a client computing device toinitiate a secure operating system directly from the secure boot device1002 without the need for additional, dedicated hardware. The operatingsystem stored in the secure boot device 1002 causes trusted systemsoftware to be loaded and a client terminal process module, such asclient terminal process module 1102 of FIG. 11, to be executed.

In step 2604, the secure boot device 1002 receives a user's credentialssuch as client identification and a password. In other embodiments,other credentials are used to identify a user. In an example, the secureboot device receives the user's credentials via the client terminalprocess module 1102. In some embodiments, the credentials received fromthe user are sent to an authentication server to verify the user'sidentity.

In step 2608, upon verification of the user's identity, a secureconnection is established between the computing system hosting thesecure boot device 1002 and a remote server and accordingly, a desktoprunning on the remote desktop client is booted in a first language. Aswill be described in further detail, the desktop may include selectableand non-selectable user interface elements such as, for example, secureand non-secure application icons and a menu or tool bar. In thisexample, the desktop is booted in a first, default language such asEnglish. However, it is understood that any default language may be setbased on the location or preference of the user. As will be described infurther detail, the icons and associated text may be displayed indifferent languages. In an example, a user may select the desiredlanguage in the user settings feature of a toolbar.

In step 2610, the computing system hosting the secure boot device 1002receives a selection of a second language that is different from thefirst language or currently displayed language. As described herein,such a selection may be received from a settings feature of a toolbar,and in other embodiments, the selection may be accessible using adifferent desktop feature.

Upon receiving the selection of the second language, in step 2612, thecomputing system hosting the secure boot device 1002 resets the desktopin the second language. In an example, the desktop reset performed bythe computing system hosting the secure boot device 1002 does notre-start the operating system running on the secure boot device 1002,but rather, merely resets the desktop without requiring a user tore-enter credentials as was performed in step 2604.

FIG. 27 is an example screenshot of a desktop 2702 running on the remotedesktop client in a first language. As illustrated in this example, thelanguage is English and each application icon 2704, 2706, and 2708 aswell as the start menu 2710 are displayed in English. Although threeapplication icons 2704, 2706, and 2708 and a start menu 2710 aredisplayed, it is understood that more or fewer icons may be displayed.In addition to the text identifying each application icon 2704, 2706,and 2708, the text displayed when the application icon 2704, 2706, and2708 is selected is also displayed in English. For example, ifapplication icon 2704 is an internet browser application, the textassociated with the internet browser and webpages themselves are alsodisplayed in English.

FIG. 28 is an example screenshot of a desktop 2702 having a toolbar 2802for allowing the dynamic switching of languages displayed by a remotedesktop client. Continuing the example illustrated in FIG. 27, thedefault or first language displayed is English. As illustrated in FIG.28, the language may be dynamically updated, using toolbar 2802, upon auser's selection of a language from a plurality of language options.Although this example illustrates three languages (English, Spanish, andGerman) it is understood that more or fewer languages may be optionallyprovided. As illustrated in this example, the second selected languageis Spanish.

FIG. 29 is an example screenshot of a desktop operating system runningon the remote desktop client in a second language. Continuing theexample displayed in FIG. 28 wherein the second selected language isSpanish, the desktop is dynamically reset without re-booting theoperating system. Accordingly, user credentials are not required to bere-entered upon a language change. As is displayed in FIG. 29, the threeapplication icons 2704, 2706, and 2708 and a start menu 2710 are nowdisplayed in Spanish. Still further, not only is the identifying textassociated with the application icon displayed in Spanish, but so is thetext associated during operation of each application.

VII. Switching Between Multiple Brandings

Referring now to FIGS. 30-33, generally, disclosed are methods andsystems for switching between multiple brandings associated with adifferent entity from which a user may receive of a remote desktopclient. As will be described herein, the remote desktop client,accessible through a secure boot device, is configured to allow a userto be associated with multiple brandings. Each branding may beassociated with a different entity such as a school, place ofemployment, or other organization, wherein each entity provides the userwith authorization to various communities of interest and therefore aparticular set of applications. Furthermore, each branding may beassociated with different settings, desktop backgrounds, languages, andsecurity settings.

The custom content area 1128 of FIG. 11 may store specific provisioninginformation, for example a location of a secure server to connect to, aswell as various options for connection. The custom content area 1128 canalso optionally store branding information, for example to indicate theparticular user or entity distributing the secure boot device 1002 toits employee or affiliate.

FIG. 30 illustrates a flowchart of an example method 3000 for switchingbetween multiple brandings of a remote desktop client operating on asecure boot device, such as secure boot device 1002 illustrated in FIG.10. In the example illustrated, the method 3000 is performed by thesecure boot device 1002. In this example, the method 3000 begins withstep 3002 in which the operating system is initiating from the secureboot device 1002. In some embodiments, this step 3002 of initiating anoperating system from the secure boot device 1002 begins by initiallysuspending the operating system used by the client computing device,such as client computer system 1006 and thereafter rebooting using anoperating system stored on the secure boot device 1002. As describedherein, the secure boot device 1002 enables a client computing device toinitiate a secure operating system directly from the secure boot devicewithout the need for additional, dedicated hardware. The operatingsystem stored in the secure boot device 1002 causes trusted systemsoftware to be loaded and a client terminal process module, such asclient terminal process module 1102 of FIG. 11, to be executed.

In step 3004, the computing system hosting the secure boot device 1002receives a user's credentials such as client identification and apassword. In other embodiments, other credentials are used to identify auser. In an example, the secure boot device receives the user'scredentials via the client terminal process module 1102. In someembodiments, the credentials received from the user are sent to anauthentication server to verify the user's identity.

In step 3006, a selection of a first branding is received by thecomputing system hosting the secure boot device 1002. As will bedescribed in further detail herein, each user is associated with atleast one branding, wherein each branding is further associated with adifferent entity from which the user may receive authorization tooperate the remote desktop client. For example, a user may be associatedwith two brandings: a work branding and a school branding, wherein thework branding and the school branding independently provide the userwith separate authorization to operate a remote desktop client. Eachbranding may be associated with different communities of interests andtherefore, when a first branding is selected, only those communities ofinterest associated with that user's particular branding may beaccessed. For example, if a user selects a school branding, only thoseapplications associated with the communities of interest to which theuser belongs under the school branding may be accessed.

In step 3008, upon verification of the user's identity, a secureconnection is established between the computing system hosting thesecure boot device 1002 and a remote server and accordingly, a brandingand associated desktop operating on the remote desktop client is bootedin the selected branding. As will be described in further detail, thedesktop may include selectable and non-selectable user interfaceelements such as, for example, secure and non-secure application iconsthat represent scripts for running secure and non-secure applicationsand a menu or tool bar. As is described herein, the secure boot device1002 does not store any applications, but rather application scriptsthat may be operated through the secure boot device 1002. In thisexample, the selected first branding is booted, such as a schoolbranding. In an example, a user may select the desired branding in theuser settings feature of a toolbar.

In step 3010, the computing system hosting the secure boot device 1002receives a selection of a second branding that is different from theselected first branding. In an example, the second branding may be awork branding or a researching branding. As described herein, such aselection may be received from a settings feature of a toolbar, and inother embodiments, the selection may be accessible using a differentfeature.

Upon receiving the selection of the second branding, in step 3012, thecomputing system hosting the secure boot device 1002 resets the desktopin the selected second branding. The user is associated with multiplebrandings and as such, because the user had already providedauthorization information, this example does not require the user tore-provide such information. In an example, the desktop reset performedby the computing system hosting the secure boot device 1002 does notre-start the operating system running on the secure boot device 1002,but rather, merely resets the branding without requiring a user tore-enter credentials as was performed in step 3004. In some examples,the desktop reset involves the shutting down and resetting of allstealth-related processes and the current desktop, which are thenre-started for the newly selected branding. Accordingly, the branding isswitched and the user is presented with a new desktop having particularsecurity parameters. Because the operating system does not reboot, andbecause the user credentials provided by the user allowed the computingsystem hosting the secure boot device 1002 to obtain all communities ofinterest for that user, switching between brandings allows thatcomputing system to switch between communities of interest associatedwith the user without requiring reauthentication.

FIG. 31 is an example screenshot of a desktop 3102 running on the remotedesktop client in a first branding. In this example, the user isassociated with a first branding, which is the user's place ofemployment. Accordingly in this example, the user is associated withparticular security parameters that are associated with applications 1-33104, 3106, and 3108.

FIG. 32 is an example screenshot of a desktop 3102 having a toolbar 3202for switching brandings of a user. Continuing the example illustrated inFIG. 31, the first selected branding was the user's work branding. Asillustrated in FIG. 32, the user may dynamically change the branding,using toolbar 3202, upon the user's selection of a branding from aplurality of brandings with which the user is associated. Although thisexample illustrates three brandings (Work, School, and Home) it isunderstood that more or fewer brandings may be optionally provided foreach user. As illustrated in this example, the second selected brandingis the user's school branding.

FIG. 33 is an example screenshot of a desktop 3302 running on the remotedesktop client in the selected second school branding. As isillustrated, the desktop 3302 now only includes applications 1 3104 andapplication 4 3304. Accordingly, in this example, under the user'sschool branding, the user is only authorized to access application 13104 and application 4 3304.

VIII. Remote Desktop Operation within an Enterprise Using a Secure BootDevice

Referring now to FIGS. 34-38, generally, disclosed are methods andsystems for operating a remote desktop client from a computing devicehosting a secure boot device, such as secure boot device 2204illustrated in FIG. 22. More particularly, the FIGS. 34-38 generallyrefer to the operation of a remote desktop client, from a secure bootdevice, while connected to a secure enterprise network. For example,FIGS. 34-38 demonstrate the capability of a user to log into the remotedesktop client from the secure boot device 2204 connected to a clientcomputing device from within the enterprise while also having thecapability to communicate with one or more trusted endpoints within thesecure enterprise network.

FIG. 34 is a flowchart of an example method for operating a remotedesktop client from a secure boot device 2204 communicatively connectedto a secure enterprise network. In the example illustrated, the method3500 is performed by the computing system, such as client computersystem 2202 hosting the secure boot device 2204. In this example, themethod 3500 begins with step 3502 in which the operating system isinitiating from the secure boot device 2204. In some embodiments, thisstep 3502 of initiating an operating system from the secure boot device2204 begins by initially suspending the operating system used by theclient computing device, such as client computer system 2202 illustratedin FIG. 22 and thereafter rebooting using an operating system stored onthe secure boot device 2204. As described herein, the secure boot device2204 enables a client computing device to initiate a secure operatingsystem directly from the secure boot device 2204 without the need foradditional, dedicated hardware. The operating system stored in thesecure boot device 2204 causes trusted system software to be loaded anda client terminal process module, such as client terminal process module1102 of FIG. 11, to be executed.

In step 3504, the computing system hosting secure boot device 1002receives a user's credentials such as client identification and apassword. In other embodiments, other credentials are used to identify auser. In an example, the computing system hosting the secure boot devicereceives the user's credentials via the client terminal process module1102. In some embodiments, the credentials received from the user aresent to an authentication server to verify the user's identity.

In step 3506, upon verification of the user's identity, a secureconnection is established between the computing system hosting thesecure boot device 2204 and a remote server. As will be described infurther detail, the desktop may include selectable and non-selectableuser interface elements such as, for example, secure and non-secureapplication icons that represent scripts for running secure andnon-secure applications and a menu or tool bar. As is described herein,the secure boot device 2204 does not store applications or data, butrather application scripts that may be operated through the secure bootdevice 2204 upon verification of a user's identity.

As described herein, this example illustrates an embodiment in which theclient computer system 2202 hosting the secure boot device 2204, iscommunicatively connected to a secure enterprise network as furtherillustrated in FIG. 35. Accordingly, in step 3508, a secure connectionis established with a service appliance device, such as serviceappliance 2206 shown in FIG. 35. The service appliance 2206 directs theclient computer system 2202 hosting the secure boot device 2204 tocommunicate with a secure gateway device, such as the gateway device2228 illustrated in FIG. 35. The connection between the serviceappliance 2206 and the client computer system 2202 is also illustratedby the bolded arrow in FIG. 36. As is shown in FIG. 36, the secure bootdevice 2204 may have stored thereon a secure service key and an addressof the service appliance 2206. Accordingly, the secure boot device 2204is provided with initial destination information for connecting to theservice appliance 2206. In this embodiment, the connection between thesecure boot device 2204 and the service appliance 2206 is a securecommunication channel.

In example embodiments described herein, a client computer system 2202hosting the secure boot device 2204, at least when positioned within asecure enterprise network, is configured to connect to a cleartextgateway computing system, which allows the client computer system 2202to connect within the secure enterprise network without establishing aseparate secured connection, as may otherwise be required if the clientcomputer system 2202 were located external to the secure enterprisenetwork. In some embodiments, even when external to the secureenterprise network, the client computer system 2202 may connect to thecleartext gateway computing system, for example if the secure bootdevice 2204 hosts an operating system that is not supported by theStealth-based security system implemented within a secure enterprisenetwork. Details regarding connections established via a cleartextgateway computing system are described in further detail in copendingU.S. Patent Application Nos. ______ (Attorney Docket No. TN622) and U.S.Provisional Patent Application No. 62/018,802 filed on Jun. 30, 2014(Attorney Docket No. TN622.P), the disclosures of each of which areincorporated by reference in their entireties.

In step 3510, the client computer system 2202 receives, from the serviceappliance 2206, over the secure communication channel, a destinationaddress of the secure gateway device 2228. Additionally, the serviceappliance may also provide the client computer system 2202 withcommunity of interest keys and filters. As described herein, thecommunity of interest keys and filters provided to the client computersystem 2202 are based on the user credentials provided in step 3504.This communication between the service appliance 2206 and the clientcomputer system 2202 is further illustrated by the bolded arrow in FIG.37. As shown in FIG. 37, the service appliance 2206 provides the clientcomputing device with the destination address of the gateway device 2228(bolded) along with community of interest keys and filters, therebyallowing the client computer system 2202 to view and communicate withvarious endpoints connected to the enterprise network.

In step 3512, the client computer system 2202 establishes a cleartextcommunication channel with the secure gateway device 2228. As describedherein, the client computer system 2202 received, from the serviceappliance 2206, destination address information of the secure gatewaydevice 2228. In this example, the communication channel establishedbetween the client computer system 2202 and the secure gateway device2228 is a cleartext communication channel, however the data transmittedover the cleartext communication channel is encrypted. The establishedcleartext communication channel between the client computer system 2202and the secure gateway device 2228 is further illustrated by the boldedarrow in FIG. 38. Upon establishment of the cleartext communicationchannel, the client computer system 2202 can now communicate with one ormore trusted endpoints within the enterprise. Although the cleartextcommunication channel is established, thereby providing the clientcomputer system 2202 to communicate with various endpoints, the clientcomputer system 2202 may only communicate with those endpoints withinits community of interest. Accordingly, any communication, over acleartext communication channel, between the client computer system 2202and an endpoint within the enterprise is premised on each devicebelonging to identical communities of interest.

Referring now to the overall disclosure, the methods and systems of thepresent disclosure provide for both a trusted client device using asecure boot device, as well as secure and flexible access tonetwork-based services via a typically unsecured network. The methodsand systems described herein allow for concurrent secured and unsecuredcommunications, as well as concurrent updating and transactional access.

The foregoing description of the exemplary embodiments of the inventionhas been presented for the purposes of illustration and description.They are not intended to be exhaustive or to limit the invention to theprecise forms disclosed. Many modifications and variations are possiblein light of the above teaching. It is intended that the scope of theinvention be limited not with this detailed description, but rather bythe claims appended hereto.

1. A method for operating a remote desktop client from a computingsystem hosting a secure boot device, the method comprising: initiatingexecution of an operating system from the computing system hosting thesecure boot device, the computing system communicatively connectedwithin a secure enterprise network, the computing system being untrustedwithin the secure enterprise network; receiving authenticationcredentials from the user, based on verification of the receivedauthentication credentials, booting, from the secure boot device, theoperating system; establishing a secure communication tunnel with aservice appliance; receiving, from the service appliance, via the securecommunication tunnel, a destination address of a secure gateway deviceconnected to the enterprise network and community of interest keys andfilters based on the authentication credentials being verified; andestablishing a cleartext communication channel with the secure gatewaydevice, thereby allowing communication between the computing system andone or more trusted endpoints within the secure enterprise network. 2.The method of claim 1, wherein communication between the remote desktopclient and the service appliance over the first secure communicationtunnel is encrypted.
 3. The method of claim 1, wherein data communicatedover the cleartext communication channel is encrypted.
 4. The method ofclaim 1, further comprising: communicating, via a second cleartextcommunication channel, with one or more trusted endpoints within thesecure enterprise network.
 5. The method of claim 4, whereincommunication with the one or more trusted endpoints is based on a userof the secure boot device being associated with a same community ofinterest as each of the one or more trusted endpoints.
 6. The method ofclaim 1, wherein the computing system comprises a mobile computingsystem.
 7. The method of claim 1, wherein, based on detecting adisconnection of the computing system from the secure enterprisenetwork, the method further comprises: disconnecting the cleartextcommunication channel with the secure gateway device; and establishing asecure communication tunnel with the secure gateway device, therebyallowing communication between the computing system and one or moretrusted endpoints within the secure enterprise network.
 8. A computingsystem configured to communicate with trusted endpoints within a secureenterprise network, the computing system being communicatively connectedwithin the secure enterprise network but untrusted within the secureenterprise network, the computing system comprising: a programmablecircuit; a memory communicatively connected to the programmable circuit,the memory storing computer-executable instructions which, when executedby the programmable circuit, cause the computing system to perform amethod comprising: initiating execution of an operating system from thecomputing system hosting the secure boot device, the computing systemcommunicatively connected within a secure enterprise network, thecomputing system being untrusted within the secure enterprise network;receiving authentication credentials from the user; based onverification of the received authentication credentials, booting, fromthe secure boot device, the operating system; establishing a securecommunication tunnel with a service appliance; receiving, from theservice appliance, via the secure communication tunnel, a destinationaddress of a secure gateway device connected to the enterprise networkand community of interest keys and filters based on authenticationcredentials being verified; and establishing a cleartext communicationchannel with the secure gateway device, thereby allowing communicationbetween the computing system and one or more trusted endpoints withinthe secure enterprise network.
 9. The computing system of claim 8,wherein the computing system comprises a mobile computing system. 10.The computing system of claim 8, wherein the memory comprises a secureboot device communicatively connected to the computing system via awired interface.
 11. The computing system of claim 10, wherein the wiredinterface comprises a USB interface.
 12. The computing system of claim11, wherein, based on detecting a disconnection of the computing systemfrom the secure enterprise network, the memory stores instructions tofurther perform: disconnecting the cleartext communication channel withthe secure gateway device; and establishing a secure communicationtunnel with the secure gateway device, thereby allowing communicationbetween the computing system and one or more trusted endpoints withinthe secure enterprise network.
 13. The computing system of claim 8,wherein communication between the computing system and the serviceappliance over the secure communication tunnel is encrypted.
 14. Thecomputing system of claim 8, wherein data communicated over thecleartext communication channel is encrypted.
 15. A secure system foroperating a remote desktop client from a secure boot device positionedwithin a secure enterprise network, the method comprising: a clientcomputer having a secure boot device connected thereto, the clientcomputer communicatively connected within a secure enterprise network,the client computer being untrusted within the secure enterprisenetwork; a remote server communicatively connected to the clientcomputer via a communications network; and a trusted set of processingmodules stored in the secure boot device that, when executed on theclient computer, cause the client computer to: initiate an operatingsystem from the secure boot device; receive authentication credentialsincluding a user identification and a password; based on authenticationof the received credentials, boot, from the secure boot device, theoperating system; establish a secure communication tunnel with a serviceappliance; receive, from the service appliance, via the securecommunication tunnel, a destination address of a secure gateway deviceconnected to the enterprise network and community of interest keys andfilters based on the authentication credentials being verified; andestablish a cleartext communication channel with the secure gatewaydevice, thereby allowing communication between the client computer andone or more trusted endpoints within the secure enterprise network. 16.The secure system of claim 15, wherein communication between the remotedesktop client and the service appliance over the first securecommunication tunnel is encrypted.
 17. The secure system of claim 15,wherein data communicated over the cleartext communication channel isencrypted.
 18. The secure system of claim 15, further comprising:communicating, via a second cleartext communication channel, with one ormore endpoints connected to the secure enterprise network.
 19. Thesecure system of claim 18, wherein communication with the one or moreendpoints is based on a user of the secure boot device being associatedwith a same community of interest as each endpoint.
 20. The securesystem of claim 15, wherein the computing system comprises a mobilecomputing system.